Repository navigation
fix(net): a FETCH never stalls on a parked open group - #5365
Conversation
When the last reader leaves mid-group, the front parks a warm copy that rebuilds the open live-edge group, and nothing writes to it again. A FETCH answered from that copy got the cached frames and then waited forever. An unfinished group in a warm segment is now a FETCH miss, and a fetch never latches onto a warm segment, so its own demand re-splices the track and the FETCH goes upstream on the new copy. Release only: main deleted the warm copy in #4741. Closes #5348 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
kixelated
left a comment
There was a problem hiding this comment.
Automated review by review (OpenAI)
Reviewed commit 9a50b9f against release (0393334).
No actionable bugs found. The two guards address both ways a FETCH could get stuck on the parked copy: cached incomplete groups miss, and upstream requests wait for a live replacement. Finished cache hits remain available, and the existing demand lifetime supplies the re-splice. This is a suitably narrow fix that preserves live subscribers' open-group continuation.
Inspected all three changed files and surrounding cache, demand, park/takeover, group-completion, and mock-session code. Verification was static through GitHub; I did not execute tests. CI was still running when checked, so this does not establish a test pass.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9a50b9f273
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
Merge summary:
(Written by Claude Opus 5.5) |
Problem
On the 0.17 line, a FETCH of a group that a live subscription delivered only in part, after that subscription went idle, returns the cached frames and then hangs forever (#5348). When the last reader leaves mid-group, the front parks a warm copy (
warm_copy/warm_rebuildinmodel/origin.rs) that rebuilds the open live-edge group, and nothing writes to it again.resume::Consumer::cached_groupserved that open copy as a FETCH hit, and no upstream SUBSCRIBE or FETCH followed.Seen downstream as a recorder restarted within the cache window permanently stalling a rendition.
Approach
Per
quest/m1/release-warm-fetch.mdonmain:cached_grouptakes afinishedflag, set for warm segments).Fetching::poll_latchnever latches a warm segment. The pending fetch holds demand, the front re-splices, and the FETCH goes upstream on the new copy.Regression:
rs/moq-net/tests/idle_cancel_refetch.rsdrives it over a lite-06 mock session. It fails onreleasewithgroup 1 hangs: Elapsedand passes with the fix.Impact
Alternatives
resume::Groupcontinuing the open warm group: more code on a linemainalready deleted (fix(net)!: resume route changes by reading the routes' copies; a path is one broadcast #4741).returning_reader_continues_an_open_warm_group).Follow-ups
mainas a guard, retiring the quest: test(net): a group cut by an idle cancel is refetched whole #5366.Closes #5348
(Written by Claude Opus 5.5)
🤖 Generated with Claude Code