fix(net): a capped IETF stream never claims END_OF_GROUP (backport #5077)

[kixelated]

Backport of #5077 (9680ca9e4) to release.

What breaks on release

When a served range (such as an absolute subscription filter) ends partway through a group, the IETF publisher caps that group's stream at the end Location. Release's GroupFlags defaults has_end: true, so the capped stream still sets the END_OF_GROUP header bit, and its FIN tells the subscriber the group ended at the cap. Any IETF peer subscribing to moq-relay (or a JS publisher) with an end Location, such as imquic testing draft-22 at the Seattle interop on 2026-10-12, would cache a truncated group as complete. Both the Rust and JS publishers had this.

What changed versus the original

• The fix itself (Rust TrackServe and JS Publisher) applied unchanged, along with the JS test updates.
• The Rust regression test is adapted: release lacks coding::decode_buf, so it decodes the header with release's ietf::GroupHeader::decode(&mut buf, Version::Draft20), and it runs under #[tokio::test] because release has no moq_net_sim.
• Quest file edits are dropped.

Public API and wire impact

No public API change. Wire: a stream capped by a range end no longer sets the END_OF_GROUP bit; uncapped streams are unchanged.

Test evidence

• cargo nextest run -p moq-net capped_group_does_not_claim: passes with the fix, fails without it.
• bun test src/ietf/publisher.test.ts in js/net: 69 pass. With hasEnd: true restored, two filter tests fail.
• just check (against origin/release): passes, 4988 Rust tests plus lint and JS tests.

(Written by Claude Opus 5.5)

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-09T22:35:40.439939Z	7a378e2	PR opened

ℹ️ 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[kixelated]

Grok review of 7a378e2e (backport of #5077 to release)

Small, correct fix: both publishers now set END_OF_GROUP only when the slice has no until cap, in Rust (TrackServe, publisher.rs ~L2318) and JS (publisher.ts ~L594). Everything else in GroupFlags stays at its default, so uncapped streams are unchanged on the wire. No blocking issues.

Non-blocking:

• The flag is conservative: a cap at or past the group's real last object also clears END_OF_GROUP, because the header is written before the end is known. That's safe (a subscriber just can't mark the group complete from this stream), but worth a release note for IETF peers that cache.
• The Rust test's doc comment says a cap at or past the real end clears the bit too, but only Some(0) and None are asserted. Add a Some(2) or Some(3) case so the documented behavior is pinned.
• CI checks are 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: 7a378e2

No new concrete correctness or security bug found in the full three-file diff and relevant surrounding code.

Direction: keep this focused backport. Deriving END_OF_GROUP from the existing slice cap in rs/moq-net/src/ietf/publisher.rs:2315–2321 and js/net/src/ietf/publisher.ts:588–602 is the simplest safe fix: capped streams stop claiming group completion, while uncapped headers and the public API stay unchanged.

Non-blocking coverage: the existing Grok review already identifies the missing boundary cases at rs/moq-net/src/ietf/publisher.rs:4431–4432. Adding Some(2) and Some(3) assertions would pin the documented behavior for a cap at or beyond the real end.

Verification limits: GitHub-only source review, including range selection, header encoding, stream termination, and tests. I did not run builds, tests, or cross-language interop. At the final recheck, the PR remained open/non-draft on this SHA, with eight checks queued and Auto-merge skipped; no CI pass verified.

[kixelated]

Re: the Grok review and the OpenAI review: added Some(2) (cap at the last object) and Some(3) (cap past it) assertions to capped_group_does_not_claim_its_end in 1aec3e6. Both clear END_OF_GROUP as the doc comment says, since the header is written before the publisher knows where the group ends. No bug found; cargo nextest run -p moq-net capped_group_does_not_claim passes.

(Written by Claude Opus 5.5)

[kixelated]

Follow-up review at 1aec3e6f (since 7a378e2e)

The push is test-only: serve_tests in rs/moq-net/src/ietf/publisher.rs now asserts that a cap at the last object (Some(2)) and past it (Some(3)) both leave has_end unset. That addresses the earlier note that the test didn't pin the cap-at-or-past-the-end case. No logic changed.

Still open (non-blocking): that behavior (a cap at or past the real end also drops END_OF_GROUP) is now intentional and tested, so it's still worth a line in the release notes. CI is 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: 1aec3e6

Follow-up to my previous review: the only delta is two regression assertions in rs/moq-net/src/ietf/publisher.rs:4432–4433. With three objects numbered 0–2, Some(2) and Some(3) correctly check caps at and beyond the real end. This addresses the prior coverage note, also confirmed in the existing follow-up review.

No new actionable findings. Direction remains sound: extend the existing test; no production logic, API, wire, or dependency changes in this push.

Verification: GitHub-only comparison against 7a378e2 and inspection of the test helper. Same release base, one direct descendant commit. I did not run tests or builds; current-head checks remain queued/in progress. Rechecked open/non-draft state, head, and reviews before posting.

[kixelated]

Merged release into the branch (99f092c0). The only conflict was test-only: both sides appended to serve_tests and all tests are kept; non-test code merged cleanly with both fixes intact. just check origin/release passes. The maintainer treats this as trivial since the OpenAI review of 1aec3e6f; auto-merge is armed for when Check and macOS finish.

(Written by Claude Opus 5.5)