Repository navigation
test(transcode): own live source progress and clock - #7822
Conversation
Quest-Claim: 53ebaecab0df0e67
Co-Authored-By: GPT-6.1 Sol <noreply@openai.com>
…2/transcode-multi-rung Co-Authored-By: GPT-6.1 Sol <noreply@openai.com>
|
No actionable comments were generated in the recent review. WalkthroughThe live multi-rung tests now use a shared helper that builds a pipeline, publishes three five-frame groups, and checks each requested rung’s output. The helper uses a manual clock, and the software, hardware, and VA-API tests call it. The Severity of issue fixed: Low Merge Risk:
|
kixelated
left a comment
There was a problem hiding this comment.
Automated review by review (OpenAI)
Reviewed head 941d324.
No actionable issue found. The new fixture attaches each rung to the shared live feed before publishing, waits for every rung's group FIN before advancing the source, and checks all groups and frame timestamps. I also checked the manual-clock setup and the surrounding end-to-end coverage.
Verification: GitHub-only static review. I did not run the tests or verify hardware execution independently; the GitHub check was still running during review.
(Written by review (OpenAI))
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
Reviewed the full 4-file diff at head
941d32473: a test-only replacement of the flaky real-time live multi-rung fixture.
- Deterministic fixture:
live_groupsinstalls akio::clock::Manualclock and drives the productionpipeline::Pipeline/rung::servehandlers group by group instead of pacing a real-time source. Each rung'sservefuture is polled once to attach it to the shared feed before any media is published.- Feed-safe sequencing: publishes the next source group only after every rung reads the current one through FIN, then advances the clock by that group's media duration. One group outstanding at a time keeps each rung's listener far under the 16-item feed capacity, so the
Lagged/Cancelpath the old fixture hit is structurally unreachable.- Stronger assertions: all three group sequences are checked per rung for sequence number, Annex-B start code, five-frame count, and exact source timestamps — the previous fixture only drained group 0.
- Shared across backends:
live_multi_rung,live_multi_rung_hardware, andvaapi_live_keeps_the_buffered_tail_in_its_groupall route through the helper and now usestart_paused = true; the VAAPI buffered-tail regression check is preserved (a tail moved into the next group would break the frame count/timestamp assertions).- Bookkeeping: removes the completed quest file and its epic link, and adds the dev-only
manualfeature tokioinrs/moq-transcode/Cargo.toml.
deepseek-v4.1-flash-1017 (free via Pullfrog for OSS) | 𝕏
…2/transcode-multi-rung
|
quest land watch: the merge queue removed this pull request at 1a16912 because it conflicts with The land fixer works on it in the background, and the watcher re-enqueues it at the back of the queue once it is fixed or judged flaky, or hands it back here with what it needs. (written by quest land watch) |

Problem
The live multi-rung fixture publishes groups every 100 ms while native codec threads run independently. Under encoder load it overruns the shared 16-item feed and receives
Cancelwhile draining the first output group.A diagnostic CPU workload on each rung's first encode reproduced the exact line-550 panic in 3/3 runs. Both listeners reported
Lagged(3)and cancelled group 0 after one frame. No encoder restart or source-decode failure occurred.Approach
Impact
Alternatives
Paused tokio alone advances while native codec threads are busy. Wall-clock pacing depends on host load. Directly driving the existing handlers avoids introducing production readiness hooks; existing end-to-end tests still cover
run.Validation
black_box(1u64)iterations once on the first encode request for workers withconfig.resize.is_some(). All diagnostic code was removed afterward.quest gate just ci: 341 selected Rust tests passed, plus Rust formatting/docs/clippy and the other selected checks. The flake check alone failed buildinggithub-runnerbecauseunsharecannot write/proc/self/uid_mapon this host.origin/mainat 13f5e43743:nix develop --command quest gate nix flake check --print-build-logsfailed identically, on the same/nix/store/k6j6qw86x77lz6dnl2wqbxi86cjy31yw-github-runner.drv.quest gate python3 .tmp/loaded-live.pyrunsjust rs test -p moq-transcode --lib -E 'test(=tests::live_multi_rung)' --stress-count 20 --no-fail-faston CPU 0 alongside 16 CPU workers pinned to that core. The helper joins every worker before exit.quest check --base origin/main: 601 documents OK.Review
mechanical fix by quest land watch:
merged main at 1b68a5983c5940792d3689e6078f3ccedca94bea with the quest merge driver(head c53c46a)Claude Code (
claude-opus-5-5, medium effort),quest reviewround 1: no findings on head 941d324735 againstorigin/mainat 13f5e43743.Head 1a16912613 merges
origin/mainat 3f39969175 to clear a conflict. The quest link-list merge driver resolvedquest/m0/test-flakes-2/README.md.git diff origin/main...HEAD -- rsmatches the reviewed head's Rust diff exactly. The only PR-diff change is surrounding context in the epic README, so the merge needs no new review. After the merge,just rs test -p moq-transcode --lib -E 'test(=tests::live_multi_rung)' --stress-count 5passed 5/5.Follow-ups
Restore developer-host Nix builder UID mappings before claiming a strict flake pass. The existing non-strict skip is already handled by moq-dev/moq#7763; no change to that policy is proposed here.
(Written by GPT-6.1 Sol; merge update written by Claude Opus 5.5)