Repository navigation
fix(files): cap how long a room delivery waits for its refetches - #9427
Conversation
The coalescing in #9419 awaits each delivery's refetches before the next one starts, so a refetch still in flight is neither cancelled nor overlapped. A fetch has no timeout of its own, so one that hung held the room's deliveries forever and the tab stopped picking up remote changes. Each delivery now waits at most DELIVERY_SETTLE_CAP_MS; past it, the next delivery's invalidation cancels and restarts the hung fetch, as every broadcast did before coalescing. Autopsy: the coalescing tests covered a refetch that settles late, never one that does not settle.
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
[Medium impact] The PR appears safe to merge. SummaryCaps how long each room delivery waits for its refetches.
|
There was a problem hiding this comment.
All reported issues were addressed across 2 files
Reply with feedback, questions, or to request a fix.
Turn on auto-fix | Re-trigger cubic
|
@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.
All reported issues were addressed across 2 files
Reply with feedback, questions, or to request a fix.
Turn on auto-fix | Re-trigger cubic
|
@cubic-dev-ai review this PR |
@waleedlatif1 I have started the AI code review. It will take a few minutes to complete. |
Summary
DELIVERY_SETTLE_CAP_MS(60s, above the slowest list read) via the existingwithinDeadlinehelper, which clears its timer; past it, the next delivery'sinvalidateQueries(cancelRefetch: true) cancels and restarts the hung fetch, the recovery every broadcast gave before coalescingType of Change
Testing
bun run lint,bun run check:audits(61),bun run type-checkChecklist
test-auditauthoring gate)