Honor serve refresh interval - #398
Conversation
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
ceiling | 29cf7b1 | Commit Preview URL Branch Preview URL |
Aug 23 2026, 06:48 PM |
|
Warning Review limit reached
Next review available in: 20 minutes Limit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?Wait for the limit to reset, then comment An organization admin can change what happens after included review limits in Billing. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_718ef1a8-a851-4017-86fe-f279e8c3714f) |
# Conflicts: # CHANGELOG.md
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_4da60165-c065-46f7-a812-51246aca3fad) |
# Conflicts: # CHANGELOG.md
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_752bc31c-1fa2-4212-be5c-e08e3f1d04eb) |
Closes #83. Extends the `## serve` section of `docs/CLI.md` with a `### HTTP endpoints` subsection, per your comment on the issue — no separate `docs/SERVE.md`, and nothing else in the section touched. What it documents: - The three routes (`GET /health`, `GET /usage`, `GET /cost`) and the `provider` query param, including `both` / `all` and the default of querying the providers enabled in Settings when the param is omitted. - The full error surface as a table: `400`, `401` (bearer token on `/usage` and `/cost`, `/health` exempt), `403` (non-local `Host`), `404`, `405`, `409` (`no_enabled_providers`), `503` (connection cap). - Array response semantics: one object per requested provider, per-provider fetch errors reported inside the entry with the HTTP status still `200`, and error text normalized to `"provider request failed"` without `--include-identity`. - `/cost` scope: Claude, Codex, and Grok; `"supported": false` for the rest; fixed 30-day window (the `cost` subcommand's `--days` flag does not apply). - The local-only posture: the `127.0.0.1` bind plus the `Host`-header check, and that every route is read-only. - Three `curl` examples with sample JSON shapes, reusing the `$TOKEN` from the existing example above rather than repeating the token setup. One note: your heads-up about the `--refresh-interval` prose resolved itself while this was in flight — #398 wired the cache up, so the section is written against current behavior (post-#398/#325, v1.5.36) and doesn't touch the flag descriptions. How verified (docs-only change, so verification was against the running server): ``` cargo build --manifest-path rust/Cargo.toml -p codexbar target/debug/codexbar serve --port 8124 ``` Then curl-checked every documented behavior against the built 1.5.36 binary: `/health` unauthenticated (response matches the docs example verbatim), `401` for both a missing and a wrong bearer token, `400` on an unknown provider, `403` via a forged `Host: example.com`, `404`, `405`, `/cost?provider=claude` matching the documented shape and key order, and `/cost?provider=grok` returning `"supported": true`. <!-- Macroscope's pull request summary starts here --> <!-- Macroscope will only edit the content between these invisible markers, and the markers themselves will not be visible in the GitHub rendered markdown. --> <!-- If you delete either of the start / end markers from your PR's description, Macroscope will append its summary at the bottom of the description. --> > [!NOTE] > ### Add HTTP endpoints section to `docs/CLI.md` > Documents the serve HTTP API: routes (`GET /health`, `GET /usage`, `GET /cost`), the `provider` query parameter, and response shapes including per-provider error reporting. Also covers the 30-day scan window limit, supported providers for `/cost`, the standardized JSON error format with status-specific conditions (400, 401, 403, 404, 405, 409, 503), and example curl invocations. > > <!-- Macroscope's review summary starts here --> > > <sup><a href="https://app.macroscope.com">Macroscope</a> summarized 8337efa.</sup> > <!-- Macroscope's review summary ends here --> > <!-- Macroscope's pull request summary ends here --> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added documentation for the local server’s HTTP API. * Clarified available read-only routes, authentication, provider selection, response formats, and error handling. * Documented localhost binding, Host validation, supported cost providers, concurrency limits, and usage examples. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
1 participant
Fixes #273.
Caches successful usage and cost responses for the configured TTL, with separate route and provider keys. A zero interval disables caching, and provider failures are not cached. Includes deterministic cache tests and CLI documentation.
Note
Medium Risk
Changes local serve API freshness: clients can receive stale usage/cost for up to the TTL, and failed provider fetches are no longer cached. Loopback-only, no auth or credential changes.
Overview
codexbar serve --refresh-intervalnow actually caches responses (it was previously unused). Successful/usageand/costbodies are stored in memory for that TTL, keyed separately by route andproviderquery./usageis cached only when every provider fetch succeeds;/costonly on HTTP 200. Failures are retried on the next request.--refresh-interval 0disables the cache.Clients polling within the TTL may see stale numbers. Docs and changelog updated for #273.
Reviewed by Cursor Bugbot for commit 29cf7b1. Bugbot is set up for automated code reviews on this repo. Configure here.
Note
Cache
/usageand/costresponses inservebased on--refresh-intervalserve --refresh-intervalflag now sets the TTL for an in-memory cache of successful/usageand/costHTTP responses, stored per route and per provider selectionResponseCachein serve.rs skips reads and writes when TTL is zero;/usageresponses containing any provider error are not cached, and/costcaches only200responsesroute_requestnow holds aMutex<HashMap>lock on every/usageand/costrequest; contended access under high concurrency could add latencyMacroscope summarized 29cf7b1.