Repository navigation
test(moq-c): keep the open range in the raw track update test - #7745
Conversation
raw_track_subscription_options_and_update updated its subscription with a one-element range array while `..subscription` kept `ranges_len` at 2, so moq-c read a second range past the array's end. When the read ended after "two", the task removed itself before the test cancelled it, and the cancel returned MOQ_ERROR_TRACK_NOT_FOUND. Pass the widened range alongside the open far-ahead range with a matching length, as the test's comment intends. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
kixelated
left a comment
There was a problem hiding this comment.
Automated review by review (OpenAI)
Reviewed head 97bbed0 against base e5ec95c. No actionable findings. The updated test retains the open range and passes the matching array length while widening the bounded range.
Verification: static review of the patch and surrounding test and range semantics via GitHub. I did not run the test or reproduce the reported flake.
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
Test-only fix for the flaky raw_track_subscription_options_and_update in rs/moq-c/src/test.rs.
widenednow keeps the open range: the update is built from[widen(ranges[0]), ranges[1]]instead of a one-element array, andranges_len: widened.len()replaces the inherited value. This removes the out-of-boundsmoq_rangeread and keeps the read open so themoq_consume_track_cancelassertion no longer races the consumer's self-removal.
The fix matches the test's own comment at rs/moq-c/src/test.rs:2197 that an open far-ahead range keeps the read alive, and it closes the root cause (parse_subscription reads exactly ranges_len entries, api.rs:844) rather than papering over it. I checked the other moq_subscription constructions in this file: all use ranges_len: ranges.len(), and ..subscription appears nowhere else, so there is no sibling instance of the same mismatch. No sleeps or assertion changes.
deepseek-v4.1-flash (free via Pullfrog for OSS) | 𝕏
|
No actionable comments were generated in the recent review. WalkthroughThe test now checks that widening the bounded subscription range from groups 1..2 to 1..3 preserves the existing open-ended range. The update uses a two-entry range array and sets Merge Risk:
|

Fixes the flaky
test::raw_track_subscription_options_and_updateinrs/moq-c/src/test.rs. The flake keeps knocking PRs out of the merge queue, including moq-dev/moq#7498, moq-dev/moq#7690, and moq-dev/moq#7722.Cause
The test builds its update from a one-element
widenedarray but spreads..subscription, soranges_lenstays 2. moq-c then reads a secondmoq_rangepast the end of that stack array, which is undefined behavior in the test. Either way, the update drops the open far-ahead range. The test's own comment says that range keeps the read open. Without it, the read ends after delivering "two", and the consumer task removes itself. When that wins the race against the test'smoq_consume_track_cancel, the cancel returns-27(MOQ_ERROR_TRACK_NOT_FOUND) at the cancel assert.The implementation behaves as documented: a read whose ranges have all ended closes, and the cancel then reports the consumer as gone. The bug is in the test, so only the test changes.
Fix
The update now passes
[widened, ranges[1]]withranges_len: widened.len(). That keeps the open range, as the comment intends, and the length matches the array. There are no sleeps and no timeout changes.Reproduction
The loop runs the test binary 600 times with
xargs -P 32on a 24-core host:main(e5ec95c)main(e5ec95c), rerunEvery failure on
mainwas attest.rs:2285, themoq_consume_track_cancelassert, withleft: -27.Checks
just rs check-test -p moq-c: passedquest review --base origin/main(Codex gpt-6.1-sol): 0 findingsReview
Head 97bbed0:
quest reviewwith Codex found nothing.(Written by Claude Opus 5.5)
🤖 Generated with Claude Code