Repository navigation
perf(auth): stop blocking requests on best-effort last-used timestamp writes - #8910
Conversation
… writes The API key lastUsed update and the desktop device lastSeenAt update are display-only, but every request awaited them. When the primary's commits wait on synchronous replication, these single-row writes stall for the whole episode and hold the authenticated request (and the desktop inbox poll) with them. Concurrent requests on the same key also queued behind the stalled writer's row lock, each holding a pool connection. Both writes are now fire-and-forget with logged failures, following the sandbox image touch precedent. The API key write is additionally debounced per process with an LRU keyed by key id over the existing staleness window, so a hot key issues at most one in-flight write per process instead of one per request.
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
All reported issues were addressed across 8 files
Heads up: you’ve reached your flex budget. Increase your flex budget or wait for usage to reset.
Turn on auto-fix | Re-trigger cubic
 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
A process-local TTL debounce alone let a write still pending past the window, or evicted from the cache, be followed by another write queued on the same row lock. createDetachedTouch tracks in-flight keys apart from the optional debounce, so a key never has two writes pending. The desktop last-seen write takes no in-process debounce: the offline check reads it.
|
@cubic-dev-ai review this PR |
@waleedlatif1 I have started the AI code review. It will take a few minutes to complete. |
There was a problem hiding this comment.
No issues found across 10 files
Confidence score: 5/5
- Automated review surfaced no issues in the provided summaries.
- No files require special attention.
Heads up: you’ve reached your flex budget. Increase your flex budget or wait for usage to reset.
Turn on auto-fix | Re-trigger cubic
This branch was previously deployed
1 participant
Summary
lastUsedwrite, and the desktop inbox poll awaited the devicelastSeenAtwrite. When commits wait on synchronous replication, those single-row writes stalled for the whole episode and held the request with them; concurrent requests on the same key queued behind the stalled writer's row lock, each holding a pool connection.createDetachedTouch(built onrunDetached): the caller never waits, and a key never has two writes pending, so a stalled commit can't stack writes on the same row lock. The API key write is also debounced per process over its existing staleness window; the desktop write is not, because the offline check readslastSeenAtand its SQL guard already bounds the write rate.Type of Change
Testing
lib/core/utils/background.test.ts: caller doesn't wait, repeats inside the interval are skipped, no overlapping write while one is pending (fails without the in-flight guard), a failed write releases its keylib/api-key/service.test.tspassesChecklist
test-auditauthoring gate)