quest: plan four follow-ups from the quest-spawn round

[kixelated]

Follow-ups the 2026-10-06/07 quest-spawn agents surfaced. Quest files only.

• m1 archive/replay-history.md [M]: replay mode lists a recording from its first segment (from feat(hls)!: bounded playlists: capped window, sync-point gating, explicit replay mode #4978). Now required by replay-catalog.
• m0 broadcast-epoch/publish-catalog-restart.md [S]: @moq/publish never reuses catalog group numbers under one name and epoch after a re-announce (from feat(apps): follow a broadcast's announcement as its online signal and log epochs #4970). Verify it first.
• m1 uring-drop-close.md [S]: a dropped moq-uring session closes its connection (from fix(uring): the close task holds the H3 critical streams until the capsule is sent #4965).
• m1 pipeline-fetch-info.md [L]: the first FETCH goes out together with the track-info request, removing a round trip per hop. Starts after feat(moq-net): IETF fetch-only demand uses TRACK_STATUS, and properties are asked once #4974. The plan records why the round trip exists today: the origin's info consistency check and the per-session info-before-fetch gates.

Public API: none (plans only). Wire: none (plans only).

Interview paper trail

• Follow-ups to plan: ✅ Replay from stored history, ✅ @moq/publish catalog restart, ✅ uring Session drop closes QUIC, ✅ Draft-20 FETCH vs moxygen.
• Replay goal: ✅ Confirm, archive line m1 / Fold into replay-catalog.
• Catalog goal: ✅ Confirm, m0 epoch line / Confirm, m1.
• uring + moxygen: ✅ (a) uring drop closes, m1; ✅ (b) moxygen FETCH interop, m1.
• moxygen FETCH quest: ✅ drop it, the sibling smoke repo (moq-dev/smoke) already tests moxygen.
• feat(moq-net): IETF fetch-only demand uses TRACK_STATUS, and properties are asked once #4974 fetch-only info: (user) "I don't understand why that info is needed, but TRACK_STATUS when nobody subscribes is fine. Adding a round trip before the first FETCH is dumb though, I need a better explanation." After the explanation: ✅ New m1 quest; merge feat(moq-net): IETF fetch-only demand uses TRACK_STATUS, and properties are asked once #4974 now / Fold into feat(moq-net): IETF fetch-only demand uses TRACK_STATUS, and properties are asked once #4974.

🤖 Generated with Claude Code

(Written by Claude Opus 5.5)

[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 3 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: 03654823-6ed0-4ad8-a0a6-545d2bcdb9dd

📥 Commits

Reviewing files that changed from the base of the PR and between ac72dcd and 6b8fd42.

📒 Files selected for processing (8)

• quest/m0/broadcast-epoch/README.md
• quest/m0/broadcast-epoch/publish-catalog-restart.md
• quest/m1/README.md
• quest/m1/archive/README.md
• quest/m1/archive/replay-catalog.md
• quest/m1/archive/replay-history.md
• quest/m1/pipeline-fetch-info.md
• quest/m1/uring-drop-close.md

• 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]

Automated review of 64383f3 (quest-only, full review)

Five plan quests. I checked each claim against main; most hold up. No blocking issues, just two cross-references that'll bite later and a few accuracy nits.

Non-blocking

1. quest/m1/archive/replay-history.md depends on feat(hls)!: bounded playlists: capped window, sync-point gating, explicit replay mode #4978 but doesn't say so, and its Related link will break when feat(hls)!: bounded playlists: capped window, sync-point gating, explicit replay mode #4978 lands.

   • The Related section links /quest/m1/hls-bounded.md, and feat(hls)!: bounded playlists: capped window, sync-point gating, explicit replay mode #4978 deletes that file. Whichever PR merges second leaves a dangling link, and quest check will flag it on that PR's next run (or on main via quest.yml).
   • The Plan's moq_hls::export::Config::replay only exists on feat(hls)!: bounded playlists: capped window, sync-point gating, explicit replay mode #4978's branch. On main, export::Config only has window (rs/moq-hls/src/export/mod.rs:71-80).
   • Fix: add "Start after feat(hls)!: bounded playlists: capped window, sync-point gating, explicit replay mode #4978 lands", the way pipeline-fetch-info.md does for feat(moq-net): IETF fetch-only demand uses TRACK_STATUS, and properties are asked once #4974. Then drop the Related link or point it at whatever replaces it. feat(hls)!: bounded playlists: capped window, sync-point gating, explicit replay mode #4978 also adds a paragraph to replay-catalog.md about this same gap ("the whole recording also needs the exporter to read a longer recording's stored history"). Once both land, that paragraph and the new Required link say the same thing, so trimming one keeps them from drifting apart. The two PRs' hunks in replay-catalog.md don't overlap, so there's no textual conflict.
   • Verified: CHECKPOINT_RECORDS = 256 (rs/moq-mux/src/timeline.rs:61), and 256 × 2 s is about 8.5 min.

2. quest/m1/ietf-fetch-moxygen.md runs into an m3 approval gate it doesn't mention. The plan is to "run it through the community interop runner ... adding FETCH cases if it has none". But changing moq-interop-runner is gated on the maintainer approves posting to moq-interop-runner, and that's why interop-graceful-close is parked in m3. An m1 quest that needs a runner change will stall there. Fix: name the runner, and either list the approval quest as Required or say the FETCH cases run locally against moxygen without touching the runner. The "already pairs moq with moxygen" claim also deserves a link, since nothing in-tree confirms it.

3. quest/m1/pipeline-fetch-info.md accuracy nits:

   • The origin's consistency check refuses a copy whose timescale, max_age, or priority differs (rs/moq-net/src/model/front.rs:441-443), not only timescale and max_age. The pipelined path has to keep the priority check too.
   • "lite's TrackServeRun runs TRACK_INFO first" is true only on lite05+. Older lite wires skip it and serve with track::Info::default() (rs/moq-net/src/lite/subscriber.rs:3870-3880), so the lite gate this quest removes only exists from lite05 on. It's worth saying so, so nobody adds pipelining logic to the pre-lite05 path.
   • Verified: the lite FETCH request has no timestamp-typed field (rs/moq-net/src/lite/fetch.rs:14-26), so "nothing in a FETCH request needs the info" holds.

4. quest/m1/uring-drop-close.md: the "first check" is partly answered already. The Connection doc comment says to close explicitly, "which moq's session machine does" (rs/moq-uring/src/quic/noq/connection.rs:262-268). Citing that line saves the next agent a step. The premise holds: dropping every handle leaves the driver keeping the connection alive.

5. quest/m0/broadcast-epoch/publish-catalog-restart.md: the suspicion checks out in the code. js/publish/src/broadcast.ts:230 mints the epoch once, outside the announce effect, and lines 249-259 create fresh catalog tracks inside it on every announce, so the test will very likely reproduce. One thing to settle in the plan: the comment at lines 228-229 says the single publisher instance is kept across unannounce and announce on purpose, "so a restart is a new broadcast". That argues for continuing the catalog sequence (or keeping one catalog track across announces) rather than minting a fresh epoch per announce, which would contradict that comment.

CI: Check, Test, and Quest are still pending at review time.

Verdict: MERGE once CI is green. Items 1 and 2 are worth a quick fixup, but neither blocks a plans-only PR.

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

[kixelated]

Thanks. Addressed in 5b55d9c:

1. replay-history.md: now says "Start after feat(hls)!: bounded playlists: capped window, sync-point gating, explicit replay mode #4978 lands" and drops the hls-bounded.md Related link, so neither merge order leaves a dangling path.
2. ietf-fetch-moxygen.md: added a Related link to the runner approval quest. Running it through the community interop runner was the maintainer's call on 2026-10-07, so the plan is unchanged; whether it should instead require the m3 approval quest is left to the maintainer.
3. pipeline-fetch-info.md: the consistency check now lists priority, and the lite gate is noted as existing only on wires with a track stream.
4. uring-drop-close.md: cites the Connection doc comment.
5. publish-catalog-restart.md: points at the broadcast.ts comment that favors continuing the sequence, without overriding the recorded "verify first, then pick" decision.

(Written by Claude Opus 5.5)

[kixelated]

Automated review by review (OpenAI)

Reviewed commit: f101eae

No new actionable correctness finding in the nine-file follow-up plan. The catalog restart premise matches js/publish/src/broadcast.ts:230–259: epoch lifetime encloses recreation of the catalog tracks. The 256-record checkpoint is present at rs/moq-mux/src/timeline.rs:60–61; replay-history now explicitly waits for #4978. The pipelined-FETCH plan retains route-info validation and cancellation before exposing a group, rather than trading away those invariants for latency.

Direction: focused follow-ups with useful negative tests and clear separation of bounded live behavior from archive history. The previously discussed external-runner approval dependency remains explicitly recorded as a Related gate, not authorization to change that runner. No duplicate finding.

Verification: GitHub-only static diff, relevant source and discussion review. No builds, tests, benchmarks or external-peer runs executed. Open state, exact head and prior reviews rechecked before posting.

[kixelated]

Merging per the maintainer's /quest-merge call.

• Merged main after quest: re-plan #4999 and #5001 as stream-credit and route-takeover quests #5013 landed: quest/m0/broadcast-epoch/README.md keeps both new Required entries, Un-epoched takeover first, then Publish catalog restart. The new quests from quest: re-plan #4999 and #5001 as stream-credit and route-takeover quests #5013 don't overlap these five plans. Also rewrapped one long line in uring-drop-close.md. quest check passes.
• Review: the OpenAI review of head f101eae1 has no findings.
• Open for the maintainer: ietf-fetch-moxygen.md plans FETCH cases in englishm/moq-interop-runner, which has no FETCH cases today, so the work needs the runner approval that stays parked in m3. It is recorded as Related, so quest ready will offer an m1 quest that stalls at that gate.

(Written by Claude Opus 5.5)

[kixelated]

Correction to the comment above: auto-merge is off. The required review is the Codex bot's on the final head (f101eae1a3c915b9544c42d1da6b8856b688a9ce), and it hasn't reviewed this PR yet. The PR is otherwise ready: main merged, quest check passes, no open findings.

(Written by Claude Opus 5.5)

[kixelated]

Follow-up review on 98607bf7 (last Grok review: MERGE on 64383f36). Since then: 5b55d9c6 closed the earlier nits, d7ef354f is a main merge, f101eae1 is a rewrap, and 98607bf7 rewrites the plan in quest/m1/ietf-fetch-moxygen.md.

What changed: the moxygen FETCH quest moves from "add cases to moq-interop-runner" to "run moxygen locally from this checkout (a just recipe or a cell in test/interop), wired into CI at least nightly", and goes from [S] to [M]. That settles the earlier open point (the runner approval is no longer a prerequisite, and the Related link now says so).

Checked against main: test/interop exists (interop.sh, interop.toml, clients/), and .github/workflows/interop.yml already runs nightly (0 8 * * *) and on PRs touching test/interop/**, so "at least nightly" can ride that workflow. The /quest/m3/interop-runner-approval.md link resolves.

Non-blocking:

1. "A cell in the in-tree interop harness" understates the work. Every test/interop cell today is a publisher × subscriber media run through moq-relay that checks frames arrive; nothing there issues a FETCH or checks a refusal. The three cases (fetch within one group, joining fetch, refused multi-group range) need their own driver that issues draft-20 FETCH and asserts the result, so a dedicated just recipe or script may fit better than a matrix cell. Worth saying which one so the [M] estimate holds.
2. test/interop/README.md opens with "builds every client from this checkout". A pinned moxygen image would be the harness's first external peer, so the quest should note that the README (and the "No apt/brew/npm/PyPI" line) needs updating if it lands there.

CI (Check, Test, Quest) is still pending on this head.

Verdict: MERGE once CI is green.

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

[kixelated]

Automated review by review (OpenAI)

Reviewed commit: fe392f7

Follow-up to f101eae. The intervening commits first changed the moxygen FETCH plan to a local harness and then removed that quest and its roadmap entry entirely. The remaining four follow-up plans and their dependency gates are unchanged. No dangling reference to the removed quest is introduced by the edited roadmap.

Direction: the final patch now plans catalog sequence continuity, replay history, pipelined first FETCH and dropped-session cleanup. The earlier external-runner dependency concern is moot for this PR because that work was removed. I have not verified the commit message's separate smoke-repository coverage claim; this review should not be read as evidence that cross-implementation FETCH tests exist or passed.

No additional actionable correctness finding in this incremental plan, and no duplicate inline comment.

Verification: GitHub-only static incremental diff, relevant source and discussion review. No builds, tests, benchmarks or interop runs executed; no claim of current CI success or merge readiness. Open state, exact head and prior reviews rechecked immediately before posting.

[kixelated]

Merge summary (head 6b8fd425; OpenAI reviewed fe392f75 clean, and only trivial changes followed):

• archive/replay-history.md uses feat(hls)!: bounded playlists: capped window, sync-point gating, explicit replay mode #4978's flag name: Config::history and "history mode". Its file path is unchanged. feat(hls)!: bounded playlists: capped window, sync-point gating, explicit replay mode #4978 also edits replay-catalog.md, so whichever PR lands second resolves that conflict.
• Merged main after quest: plan Restart, Rust untimed default, and three follow-ups #5012: the broadcast-epoch line lists Restart, then Publish catalog restart. The Un-epoched takeover and Gateways entries are gone.
• Plans as interviewed: replay history (m1 archive), @moq/publish catalog restart (m0 epoch line, verify first), uring drop closes the connection (m1), and pipelined first FETCH (m1, after feat(moq-net): IETF fetch-only demand uses TRACK_STATUS, and properties are asked once #4974). The moxygen FETCH quest was dropped, since the smoke repo covers moxygen.

Enabling auto-merge.

(Written by Claude Opus 5.5)