Repository navigation
Windows native stub gate intermittently fails background-only media transport test #867
Description
On the unchanged installer PR head b826989, the native-shell-windows retry failed the native stub gate: 1,449 passed, one failed. The failing test was MediaCoreCommand.ATransportOnABackgroundOnlyAssetIsRefusedAndNamesTheLoop, native/tests/MediaCoreCommandTest.cpp:9311. The prior attempt passed that gate and instead hit the existing managed recovery issue #754.
Run: https://github.com/iamfatness/CoreVideoPro/actions/runs/38184802099 (retry). No native/media-core source changed in installer PR #866. Do not attribute this to installer retirement or waive it as a harmless runner issue. Establish whether the failure is test-state/async-decoder lifetime interference or a real media-transport defect, and make the gate deterministic without weakening the assertion.
Failure log is retained locally at installer-upgrade-retirement/artifacts/installer-retirement/ci-retry-failure.log. Unranked CI intake; owner ranking required. The latest installer-fix head has independent CI in run 38187354503.
Activity
iamfatness commentedon Oct 14, 2026
Retained PR #895 macOS Metal trial at 706a446 failed ATransportOnABackgroundOnlyAssetIsRefusedAndNamesTheLoop (MediaCoreCommandTest.cpp:9401). This is the same background-only assertion tracked here, now observed on macOS. The production and assertion lines are unchanged by #869; its D3D fixture bodies are excluded on macOS. Main e1d355a passed its Metal job, so this is not a proven baseline reproduction.
Static precondition weakness: MediaTransports marks the entry Live and inserts it before the decoder factory runs asynchronously. Waiting for transportState=live therefore does not prove decoder construction completed before asserting CountingDecoder::created==1. The failed log does not print the observed count, so this is a race exposure, not attribution of that trial. Preserve failure; exact-head CI for 291711f is running. No bounds were relaxed.
iamfatness commentedon Oct 14, 2026
Additional retained evidence from PR #895 at
706a4462022b0e08e440708412a7936220d5c9dc: macOS Metal CI failed the sameMediaCoreCommand.ATransportOnABackgroundOnlyAssetIsRefusedAndNamesTheLoopfixture, now atMediaCoreCommandTest.cpp:9401. The failing line is the finalEXPECT_EQ(CountingDecoder::created.load(), 1); that assertion and its transport setup are unchanged from the PR base. Local log:beta-release-2026-10-13-bb7b4b2/artifacts/bundle-20261014/mac-metal-895.log, line 1849.Read-only source review identifies a concrete existing precondition gap:
MediaTransports.h:580sets a newly inserted entry's state toLive, while the decoder factory runs later on the worker at line 602. This fixture waits only for transport statelive, which does not establish that decoder construction completed before sampling the global counter. A delayed worker can therefore expose count zero. The failure log omits the observed count, so this is an identified race exposure, not attribution of the retained failure; extra decoder creation or other interference remains unproven.The exact subsequent test/docs-only head
291711f6f2744e787233a34d947376689be1d81epassed the complete CI run, including macOS Metal, without changing this assertion or production transport behavior: https://github.com/iamfatness/CoreVideoPro/actions/runs/38611145194 . Keep the failed trial; this successful run does not close #867 or establish its root cause. No runtime repair or relaxed assertion was included in #895.iamfatness commentedon Oct 26, 2026
New occurrence on main, 2026-10-26: CI run 40321867546 on
8e6b97c7(the #1062 merge), job native-metal-macos, failed the same final assertionEXPECT_EQ(CountingDecoder::created.load(), 1), now atnative/tests/MediaCoreCommandTest.cpp:9567. The previous main run (8f42fe19, four minutes earlier) passed the same job, and the #1062 diff touches no media, decoder or transport source (git diff 8f42fe19 8e6b97c7 -- native/srchas no media/decoder hunks). Rerunning the failed job on the unchanged head; this stays unranked CI intake per the issue.🤖 Generated with Claude Code
test: wait for background decoder picture readiness (#867)
test: wait for background decoder picture readiness (#867)
iamfatness commentedon Nov 6, 2026
Addresses #867. The background-only transport refusal test can observe logical
livebefore the asynchronous decoder constructor runs, then sample the process-global constructor count too early. The November 6 Metal run of #1192 repeats the final assertion; its diagnostic reports zero frames but omits the actual count, so this change does not assign a hidden count to that historical trial.Wait for an actual background picture before the existing pause/play refusal and exact-one-decoder checks. A real MediaCore regression holds decoder construction behind a bounded gate, demonstrates logical Live with zero constructed decoders, then releases the worker and verifies a picture and one decoder. Failure output now includes the observed count. Refusal reasons, unknown-asset behavior, exact constructor count and readiness timeout remain strict; production code and performance thresholds do not change.
Validation: both focused real-consumer cases pass, and all 136 MediaCore command cases pass after restoring the source. Applying the old one-decoder expectation while construction is held fails exactly with
logical Live is not decoder readiness; created=0. The negative result and restored runs are retained. The first combined filter was rejected with zero matched tests, and a wrapper's positional log-check argument failed after the intended native negative result; neither is counted as a passing test. The wrapper was corrected, the intended failure was verified and the restored full command set then passed. Exact-head Windows/Metal/stub CI remains required before merge.Retained hosted failure: https://github.com/iamfatness/CoreVideoPro/actions/runs/42280987997/job/128109557028 . Local evidence: D:/CoreVideo-QA/resume-20261106/867-old-assumption-negative.log, 867-delayed-factory-positive.log, 867-refusal-positive.log and 867-restored-command-suite.log. Spec: docs/reference/background-decoder-readiness-867.md. This test repair is outside the frozen beta-2026-11-06-74495ad. Merge this prerequisite before #1192 and #1182, which carry the same test change for integration checks.
test: wait for real background decoder readiness (#867) (#1193)
iamfatness commentedon Nov 6, 2026
Merged #1193 as
5e844a3ec13c6365454d38dcdde727b981a5b610after all 17 exact-head checks passed atd0c384d589c6ef9b3849236d0d19f45f2fc8e0bc, including Metal, Windows shell/production, stub platforms and thread sanitizer.The real MediaCore consumer now demonstrates the missing guarantee under a controlled factory gate: transport can be logically Live while no decoder has been constructed. Applying the old one-decoder expectation at that point fails with created=0. Releasing the worker yields an actual background picture and exactly one decoder. The refusal regression now waits for that actual picture while preserving strict constructor count, pause/play refusal reasons and unknown-asset behavior. All 136 restored MediaCore command cases passed locally; both focused cases and the negative control are retained.
This closes the demonstrated readiness race and makes future failures report the actual count. Historical reports that omitted their count are not retrospectively assigned a cause. Production adapters and performance limits are unchanged. Evidence and the earlier failed runs remain linked above; local merge/check snapshots are
D:/CoreVideo-QA/resume-20261106/pr-1193-premerge-checks.jsonandpr-1193-merge-result.json. The published beta remains frozen at74495adeand does not contain this later test-only change.fix(shutdown): stop Program delivery when its render producer exits (#…
diagnostics: retain Mac command and native phase timing (#1178) (#1182)