fix(net): wake parked reads when stamped successors abort

[kixelated]

Problem

A read parked at a group's tail can sleep through a stamped successor's abort. Under a timestamp rewind, that abort changes the group's presentation reach and should wake the reader to re-judge its drift budget.

Approach

Watch the immediate successor's closure before judging a plain group's reach, and watch closure alongside its first timestamp when resolving a resume successor. Add mock-time regressions for plain and resumed stamped-successor aborts, plus an actual cache-GC eviction before the successor's first frame. Remove the completed quest and its references. Add a parked-read benchmark swept over cached groups and readers.

Impact

• Public API: none.
• Wire: none.

Validation

• Before the fix: both stamped-successor abort wake assertions failed; actual GC eviction already passed.
• After the fix: all three focused regressions pass; the exact-head moq-net suite passes 1,498 tests (4 skipped), exit status 0.
• Merged current main (after the trunk flip) cleanly; quest check passes and CI re-ran on the merge.

Alternatives

Waking the whole track on every group abort would broaden notifications and ownership coupling. Registering the affected reader directly preserves the existing group-local wake path.

(written by GPT-6, updated by Claude Opus 5.5)

[kixelated]

Implemented at ab385775f5d7cc7895758fc465faaf6ff90a7c70.

Both stamped-successor abort tests reproduced lost wakes before the fix, then passed after registering for closure. The mock-time test using actual cache GC eviction already passed and adds regression coverage. All three focused regressions pass, and the exact-head full moq-net suite passes 1,498 tests (4 skipped), exit status 0. Public API: none. Wire: none.

The exact-head parked-read benchmark comparison, quest validator, just check, and loom checks continue in a detached pinned-Nix process. Their results are pending, so this PR remains a draft. Recommended next step: collect those results and review before /quest-merge.

(written by GPT-6)

[coderabbitai]

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 29 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used all 4 included reviews currently available.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: b6dff0d1-36cd-4c47-84da-327bb43326c8

📥 Commits

Reviewing files that changed from the base of the PR and between 5fc2b57 and 7344895.

📒 Files selected for processing (6)

• quest/m1/2991-net-coalesce-dynamic-tracks-and-preserve-sequences-across.md
• quest/m1/README.md
• quest/m1/parked-read-wakes.md
• rs/moq-net/benches/track.rs
• rs/moq-net/src/model/resume.rs
• rs/moq-net/src/model/track.rs

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[kixelated]

Merging as approved by the maintainer, as is.

• Merged current main (post trunk flip) into the branch; no conflicts (the expected quest/m1/README.md overlap with fix(net): end JS readers at the declared track boundary #4656 resolved automatically). quest check and cargo check -p moq-net --all-targets pass locally; CI re-runs on the merge.
• Decision: kept the resume.rs half rather than waiting on the fix(net)!: resume route changes by reading the routes' copies; a path is one broadcast #4741 pump rewrite, which was deliberately skipped.
• No human or bot review landed (CodeRabbit was rate limited); maintainer approval covers it.

Auto-merge enabled on 73448950967417cd8aa805c25000e708638a01e8.

(Written by Claude Opus 5.5)

[kixelated]

Review (head 73448950967417cd8aa805c25000e708638a01e8)

Fixes a real lost-wake: a stamped successor can abort without mutating the track, so a reader parked on poll_timestamp alone never re-ran. Registering poll_closed in poll_first_start (resume successors via Successor::poll_start) and in GroupExpiry (plain same-track reach) matches the failure mode. The three regressions pin plain stamped abort, resume stamped abort, and GC eviction; quest removal is complete on this head.

Blocking

None in the diff.

Non-blocking

1. CI still pending on this head (Check / Test / Quest / WASM / Android / Windows / macOS all pending at review time; Auto-merge skipping). Re-check before merge.
2. GroupExpiry vs poll_first_start abort-race asymmetry (rs/moq-net/src/model/track.rs ~3371–3376 vs ~2592–2600). poll_first_start while-loops when the group aborts between first_servable and the check, so the next servable successor is registered in the same poll. GroupExpiry always poll_closeds once then judges: if poll_closed is already Ready (abort won the race before registration) and the new reach still leaves the held group within a non-zero max_age, the next successor is not watched until something else wakes the reader. With default max_age == 0 this is mostly academic (shrinking reach expires). Mirroring the while-loop (or re-registering when poll_closed is Ready && aborted) would close the gap for non-zero budgets.

Quest / claims

• Goal covered: stamped successor abort wakes plain + resume; eviction-before-first-frame regression present.
• quest/m1/parked-read-wakes.md deleted; README + #2991 Related links cleared on this SHA.

MERGE

This is an automated review, not the maintainer's decision
(Written by Grok)