Repository navigation
perf: keep OpenRouter and serial KV reads off the status path - #44
Merged
Merged
Conversation
GET /notes-import/status waited on an OpenRouter probe whenever the 60-second provider cache had expired at that edge (about 29% of requests last week, p99 hitting the 2 s deadline), and read KV in sequence: the kill-switch, then the provider cache, then allowances. The provider result is now stored with its check time for 5 minutes. Under a minute old it is served as is; older, it is served while waitUntil re-probes and rewrites it. Only a missing result is probed inline, and its cache write also moves to waitUntil. All KV reads start at once, and the stages still decide in order.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
GET /notes-import/statusis about two thirds of prod traffic. Over the last 7 days in Sentry its response time was p50 302 ms, p90 1.16 s, and p99 1.74 s. There were two causes:gpt-6-lunaprobe has p95 973 ms, and its p99 hits the 2 s deadline.Change
notes-import:provider-healthnow holds{healthy, checkedAt}for 5 minutes. A result under a minute old is served as is. An older one is still served whilewaitUntilre-probes and rewrites it. Only a missing result is probed inline, and that cache write also moves towaitUntil. The bareup/downvalues from before this change expire within 60 s, so they're treated as fresh.waitUntil. Without it (unit tests), a stale result is re-probed before answering, as before.Verification
pnpm test(741 passing) andtsc --noEmit. The new tests cover fresh, stale + background refresh, a failed refresh keeping the stale value, the no-waitUntilpath, the deferred write, and all four reads starting before any of them answers. Against the oldstatus.ts, 6 of them fail.doctorok and e2e 44/45 (1 skipped). Status route over HTTP:{healthy:true, checkedAt}down:no_providerserved in 14 ms, then rewritten tohealthy:truein the background; the next request was availableup: served without a probeThe Cloudflare wall-time p99 (30 s) and p999 (300 s) are a separate effect: long-lived Buddies live sockets and Notes Import progress streams count their whole lifetime as wall time. This PR doesn't target those.
🤖 Generated with Claude Code