Repository navigation
fix(net): an IETF TRACK_STATUS refused as NOT_SUPPORTED falls back to SUBSCRIBE - #5409
Conversation
… SUBSCRIBE The origin queries a new track before its first reader's subscription lands, so the IETF subscriber can send TRACK_STATUS for a reader's request. A publisher without TRACK_STATUS (the JavaScript one) answers NOT_SUPPORTED, which refused the track itself, and the downstream SUBSCRIBE failed with "unsupported". That refusal is about the method, so learn the track from SUBSCRIBE instead. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.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. |
kixelated
left a comment
There was a problem hiding this comment.
Automated review by review (OpenAI)
Reviewed 30fb5cc against base 0177c46.
No actionable bugs found in the two-file patch and relevant request lifecycle/version handling. The targeted fallback looks sound: subscriber.rs:2944–2947 returns the original pending request only for NOT_SUPPORTED, so the existing SUBSCRIBE path owns acceptance, cancellation, alias registration, and cleanup. Successful TRACK_STATUS still follows the fetch-only linger path; other refusals still reject.
Reusing Target is a simpler, localized fix than changing the track model. The new regression checks query acceptance and TRACK_STATUS→SUBSCRIBE ordering for drafts 18/19/22; it does not independently establish live data delivery or cancellation coverage.
Static review only; I did not run tests or reproduce the WASM race.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
WalkthroughWhen TRACK_STATUS returns NOT_SUPPORTED, Priority: ➖ Normal Merge Risk: ⚪ Minimal · up to
|
|
Merge summary for 30fb5cc:
Follow-ups, not part of this PR:
Enabling auto-merge. (Written by Claude Opus 5.5) |
Problem
The WASM job intermittently fails ietf cases with
unsupported(error code 3):ietf: reads a published broadcastandietf: free() cancels a pending read. It has flaked on PR branches since 2026-10-09 (runs 37992181995, 38055854662, 38088705982, 38109989381, 38110085471, 38179687337, 38184448714, 38195885210, 38344051897, 38352106340), always passing on rerun.Root cause, from the CI relay logs and a forced local repro:
broadcast.track(name)and thentrack.subscribe(..).track()hands the origin's front a new track. If the front's driver runsAction::Querybefore the subscription registers, it sees no subscription and onlyquery()s the source copy.@moq/net, which refuses every TRACK_STATUS with NOT_SUPPORTED. The subscriber rejected the track withError::Unsupported, so the front aborted it and the downstream SUBSCRIBE was answered NOT_SUPPORTED, "unsupported".In the failing CI relay logs, the relay logs
subscribe startedfor the downstream SUBSCRIBE but never sends an upstream SUBSCRIBE. Adding 50 cooperative yields betweentrack()andsubscribe()in the relay publisher madejust test wasm's ietf relay fail 3/3 iterations with the same two cases. The debug logs showedtrack status refused err=unsupportedfollowed byaborting track name=data err=unsupported.#5385 is not involved. The failure predates it, and the PR #5244 failure ran on a merge base without it.
Approach
When the publisher refuses TRACK_STATUS with NOT_SUPPORTED, the IETF subscriber now hands the request back and SUBSCRIBEs instead of rejecting the track. NOT_SUPPORTED refuses the method, not the track. Draft-17 already learns tracks this way. Other refusals (not found, unauthorized, ...) still reject the request.
track_statusnow returns theTargetto continue with instead of anIdlecopy.Impact
Tests
an_unsupported_track_status_subscribes_instead(drafts 18, 19, 22) fails without the fix: the query resolvesUnsupported.just checkpasses.Alternatives
@moq/net. Worth doing for interop, but a Rust subscriber should still survive a peer that refuses it.Follow-ups
(Written by Claude Opus 5.5)
🤖 Generated with Claude Code
Need help on this PR? Tag
@codesmith-botwith what you need.