Repository navigation
quest: plan pinned requests, catalog epochs, and fetch budgets - #5291
Conversation
Co-Authored-By: GPT-6 <noreply@openai.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. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
WalkthroughThe pull request adds quest plans and updates existing plans for broadcast-reference pinning, retired-handle requests, duplicate delivery during route handover, and Priority: ⬇️ Low Merge Risk: ⚪ Minimal · up to This change updates quest plans without changing runtime behavior. The plans consistently describe FETCH freshness, fill timeouts, and future IETF epoch verification, so no merge-blocking risk is established. Pre-merge checks |
 |
| Check name | Status | Explanation |
|---|---|---|
| Title check |  |
The title clearly summarizes the main planning changes: pinned requests, catalog epochs, and FETCH budgets. |
| Description check | |
The description directly explains the planning scope, added quests, catalog pinning, FETCH budgets, IETF timeout handling, validation, and follow-ups. |
| Docstring Coverage | |
No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0… |
| Linked Issues check | |
Check skipped because no linked issues were found for this pull request. |
| Out of Scope Changes check | |
Check skipped because no linked issues were found for this pull request. |
✨ Finishing Touches
-
✨ Simplify code
-
- Commit to this branch
- Create a new PR
-
- Autofix · 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.
Comment @coderabbitai help to get the list of available commands.
1 participant
Problem
The resume audit reproduced replacement content returned by an old Rust track's FETCH, new JS metadata requests through retired handles, and duplicate delivery after the resume layer forgets 1,024 group IDs. Existing quests also disagree on catalog sibling following and historical FETCH budgets.
Approach
Add m0 quests for retired request validity, resume duplicate suppression, and catalog reference epochs/pinning. Add m1 quests for FETCH max-delay and native IETF FILL_TIMEOUT. Reconcile expiry, DROP, range, handover, identity, and lite-07 cut plans. Source pinning stays with #5252, whose latest implementation already seeds the catalog handle; fresh JS consume selection stays with #5254.
Historical FETCH uses publisher max-age when max-delay is omitted, or the tighter limit when supplied. Catalog references gain optional epochs and pin their first resolved instance; epochless transports remain best effort. Reuse FILL_TIMEOUT for upstream waiting while enforcing content freshness locally, with no new IETF age extension.
Impact
Alternatives
Keep players following siblings while exporters pin them; exempt historical retrieval from reader delay; refuse unverified catalog epochs on legacy wires; default FETCH to zero delay; add a custom IETF content-age extension. The maintainer chose the alternatives recorded below.
Validation
quest check: 470 documents valid.just check: passed in the Nix environment.git diff --check: passed.Follow-ups
Implement the new quests at their recorded priority. Wall-clock expiry, DROP, seamless JS handover, and the separately planned IETF epoch extension stay m1. Update existing docs and matching drafts with each implementation; no separate guide.
Interview decision prompts and selected answers
1. Goal and scope
Proposed goal: catalog, media, and FETCH stay on one broadcast identity; resume never duplicates content; expiry and DROP reliably end waits, while preserving epochless clients.
1.2. Release priority
1. A.3. Historical FETCH versus live delay
2. B, we should not cache longer than the publisher max age.4. Catalog references to siblings
The epoch plan said named references follow replacements; Source instead pins each sibling after first resolution.
3. A, and add an epoch field to the catalog.5. Clarify publisher retention versus reader delay
With publisher max-age 60 seconds and reader max-delay 100 ms:
B we should add max-delay to FETCH if it doesn't exist already.6. Catalog epoch placement
1. A.7. Explicit epoch over an epochless transport
2. B.Known mismatches still fail. An unverified catalog value does not make epochless routes interchangeable.
8. FETCH default max-delay
3. C.9. Wire scope before checking native IETF parameters
4. B shouldn't there be a delivery timeout parameter? Not quite the same but close enough.10. IETF scope after checking the specification
DELIVERY_TIMEOUT and its later object/subgroup forms apply to subscriptions, not FETCH. FILL_TIMEOUT from draft-18 bounds total waiting for missing upstream objects, not cached content age.
sure, accepting the recommendation.References: draft-22 timeout parameters, native cache duration. The plans retain native IETF retention semantics rather than treating unlike clocks as equivalent.
(Written by GPT-6)