Repository navigation
test(moq-relay): bitrate cap tests run on the QUIC simulator - #8812
Conversation
Quest-Claim: 5173a3367ab01257
The tokio half of bitrate_caps now serves on kio's QUIC simulator and asserts the capped transfer's time within a window in simulated time, so a throttle far below the cap fails and the test no longer waits on the real clock. The io_uring half stays on real sockets. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
There was a problem hiding this comment.
ℹ️ No critical issues — one stale doc comment inline.
Reviewed changes
I reviewed the move of the tokio half of the relay bitrate-cap tests onto kio's QUIC simulator, plus the shared Dial plumbing.
Dialenum:Real(io_uring) andSimvariants build the clients, raw endpoint, URL, and address, sotransfer,held_to_its_caps, andwindow_opens_once_admittedare shared by both halves.- Sim half: serves
Connection::runthroughquic_sim::serveoverAuth::embeddedon a clean link, and asserts each capped transfer withinLEAST..=FRAME * 8 / RATEin simulated time. - Window test: the blocked write is no longer spawned. It is a pinned future polled in a biased
select!alongside each wait. - Gating:
bitrate_capsbuilds only withtest-supportor the io_uring workers.sh/rs/select.shturns onmoq-relay/test-support(through the bench'srequired-features) andmoq-relay/io-uringon Linux, so both halves stay in the merge gate. quic_simexports:PORT,PUBLISHER,SUBSCRIBER,ip,Relay, andservebecomepub(crate)for reuse.
claude-opus-5-5 | 𝕏
|
quest land watch: ended this pull request's pick, disarming its auto-merge, since its head dafdc7d is held by finding by pullfrog[bot]: The module doc still says these tests cover "the tokio listener", but the sim half never builds a (written by quest land watch) |
|
No actionable comments were generated in the recent review. WalkthroughThe bitrate-cap integration tests now use shared helpers for simulated QUIC and real io_uring transports. Simulator tests check lower and upper transfer-time bounds. io_uring tests check the lower bound and skip unsupported workers unless Merge Risk:
|
…ay's listener Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
I reviewed what changed since the prior Pullfrog review (dafdc7d).
- Module doc fix: the
bitrate_caps.rsheader now says the simulator runs the relay'sConnectionbehind a moq-tokio server, notRelay's own listener. This resolves my earlier stale-doc comment.
claude-sonnet-5-5 | 𝕏

Finishes quest/m1/bitrate-cap-sim.md, which this PR deletes.
Summary
The tokio half of
rs/moq-relay/tests/integration/bitrate_caps.rsnow serves on kio's QUIC simulator (quic_sim, #8709), so the capped transfer's time is exact and asserted within a window in simulated time, and neither tokio test waits on the real clock. The io_uring half stays on real sockets and keeps its lower bound.Dialenum names where a relay is and builds its clients and raw QUIC endpoint (Realfor io_uring,Simfor the simulator), so the transfer and SETUP-window bodies are shared by both halves.quic_sim::serveoverAuth::embedded, answered throughAdmissionsas before;quic_simexports the pieces it reuses.window_opens_once_admittedno longer spawns a task (the sim spawn is not tokio's): the blocked write is polled alongside each wait.bitrate_capsnow builds only withtest-supportor the io_uring workers, since each of its listeners needs one.Impact
Public API: none. Wire: none. Test-only.
Validation
cargo test -p moq-relay --features test-support,io-uring --test integration -- bitrate_caps: all 4 pass (sim and io_uring, 2.4 s total; the sim pair 0.7 s).700 ms..=2.097 s.RATE / 4takes 7.5 s (above the window); no cap takes 672 ns (below it).cargo clippy --testsis clean with default features,io-uring,test-supportalone, and--all-features.Decisions
Choices made without asking, each open to review:
FRAME * 8 / RATE(2.097 s): the time at the cap with no burst credit at all, so anything slower is throttled below the cap. Observed is about 1.14 s, so this catches a throttle of roughly 2x or worse; a tighter bound (say 1.5 s) would catch a 30% throttle at the cost of a number tied to the simulator's pacing. Recommendation: keep the derived bound.LEAST(700 ms), unchanged.Dialcarries real and sim variants rather than duplicating the bodies, with thecfggating inmain.rs. The alternative, two copies oftransfer, was larger.Connection::runoverquic_sim::serveand does not go throughRelay::load, so the sim half no longer exercisesRelay's own listener wiring (the[quic]config defaults); the io_uring half still does. Recommendation: accept, as the quest asks for the simulator andConnection::runis the admission and cap code under test.bitrate_caps.rsnames the simulator and says it runsConnectionbehind a moq-tokio server, notRelay's listener (rejected: refuting Pullfrog's finding, since the doc's "tokio listener" wording was wrong for the sim half; rejected: adding aRelay-listener test to this file, outside the quest's goal). Recommendation: keep.Follow-ups
None.
Models
Size: S
Implementer: Claude Code, claude-sonnet-5-5, high effort (iterate, S, arm B)
Review
Rewritten by
quest reviewafter each round.Head: 833a639
Base: origin/main at d09ca93
Risk: medium,
the base has no RISK.md to name what is always high or customer-facing, so every change is mediumClassified: medium by default
Reviewer: Codex, gpt-6.1-sol, medium effort
Session:
01a1df2b-a013-7470-9cd9-92164930b7b5, round 2Score: 10/10,
The incremental change only clarifies the test documentation to accurately describe the simulator setup, with no actionable findings; builds and tests were not run as instructed.Rounds: 2; first round 0; findings 0: fixed 0, refuted 0, open 0
Findings: none