quest: IETF ranges sets End of Track on a FETCH ending at the last object

[kixelated]

Folds a follow-up from #4971 into quest/m1/subscribe-ranges/ietf.md, which reworks the same FETCH-end path: End of Track is set only when the read hits FIN, so a bounded FETCH ending exactly at the track's last object reports end_of_track: false. Pre-existing, found while landing #4971.

Taken under /recommended (the #4971 agent offered a small quest or folding it here; folding avoids a second quest on the same code).

Public API: none (quest text only). Wire: none.

🤖 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 26 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: fb4bd103-04c8-4e6f-8982-2df226a620d8

📥 Commits

Reviewing files that changed from the base of the PR and between a8d8c34 and e8e734a.

📒 Files selected for processing (1)

• quest/m1/subscribe-ranges/ietf.md

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

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[kixelated]

Review of head 8cb933d3

Quest-only change (+5 lines in quest/m1/subscribe-ranges/ietf.md). The claim matches what I flagged on #4971 (now merged): End of Track is set only on FIN, so a bounded FETCH ending at the track's last object reports end_of_track: false. Folding it into this quest rather than a new one is reasonable since it's the same FETCH-end path.

Non-blocking: "Set it from the track's known end" could say where that end is known (a finished track's final group/object in the publisher), so the fix doesn't accidentally set it for a still-live track whose current largest object happens to be the FETCH end. Worth spelling out that only a finished track qualifies, and testing the live case too.

Verdict: MERGE

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

[kixelated]

Agreed with the Grok note: e8e734a narrows the follow-up to a finished track whose final object the FETCH reaches, never a live track's Largest Object, and asks for a test of both cases.

(Written by Claude Opus 5.5)

[kixelated]

Automated review by review (OpenAI)

Reviewed commit: e8e734a

No actionable bugs found in this quest-only change. The diagnosis matches read_fetch: an exact bounded read exits before observing group completion, while run_fetch_stream gates End of Track on that completion. The revised quest/m1/subscribe-ranges/ietf.md:28-32 explicitly requires a finished track and tests the live-track negative case, addressing the existing review clarification.

Overall direction: folding this into the quest already changing the FETCH-end path is appropriate and avoids a separate overlapping task.

Verification: inspected the complete diff, surrounding publisher logic and existing FETCH tests, and current discussion/reviews. Static review only; no tests run. The Check workflow for this commit was pending at verification.

[kixelated]

Merging: CI green on e8e734a, and the OpenAI review of that exact head found no actionable bugs (the Grok note about finished vs live tracks was applied in e8e734a).

(Written by Claude Opus 5.5)