Repository navigation
test(verify): measure fragment spans and expect B1's 4 s fragments on macOS runners - #2789
richiemcilroy wants to merge 1 commit into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![capy-ai[bot]](https://avatars.githubusercontent.com/in/1915919?s=60&v=4){kind=small}
| [[xfail]] | ||
| case = "crash/recorder-kill/*/static-screen" | ||
| class = "fragment-span" | ||
| platforms = ["macos"] |
There was a problem hiding this comment.
The new xfail requires fragment-span on every macOS encoder path
Medium Severity
On a Mac where VideoToolbox is unavailable and encoder selection falls back to libx264, this static-screen test emits synthetic frames at 3 fps with a nominal rate of 30 fps—not runner-captured frames at 28/60 fps. libx264's 60-frame GOP therefore remains open until 20 seconds, beyond the 11-second kill. No complete fragment exists for check_fragment_spans to report, and the existing loss-time and missing entries cover that outcome. Because this new entry applies to every Mac and defaults to flaky = false, judge_with now reports the absent fragment-span class as fixed and fails the previously accepted run with XPASS. Make this allowance optional or conditional on the encoder path that produces it, while retaining its measurement bounds.
|
Found 1 test failure on Blacksmith runners: Failure
|
![Fix with [code]smith](https://pr-comments-assets.blacksmith.sh/codesmith/fix-with-codesmith-light.svg)
|
Closing in favour of #2785, which fixes the cause instead of expecting it: the in-process crash test recorded keyframe-only fragments while Studio uses timed 2 s fragments, so a static screen at ~28 fps stretched fragments to ~4 s. |
Problem
Since 2026-10-20 every pull request's macOS
crash_safetyrun failscrash/recorder-kill/inproc/static-screenandcrash/recorder-kill/oop/static-screenwithfragment-span, and so doesmain. It is not a code regression: re-running Engine verify on 2a61427, the commit that passed the nightly (run 39365191761), now fails the same way (run 39513410142).The runners now deliver the "static" screen at about 28 fps while the nominal rate is 60 fps. The keyframe interval is a frame count (2 s x nominal fps = 120 frames), so each fragment closes after about 4 s of capture instead of 2 s. That is known bug B1 (fragments are cut only at keyframes and the interval is counted in frames), already expected for this case as
loss-timeandmissing; this is the same mechanism showing up as a span check instead.Change
check_fragment_spansrecords the measured span (secs) with the problem, so the failure can carry a strict bound like every other expected failure (require_bound = true).fragment-spanentry forcrash/recorder-kill/*/static-screen, bounded to 1 to 20 problems and spans of 2.3 to 20.5 s (B1's existing 20 s ceiling). Anything outside the bound, or on another platform, still fails.Product behaviour is unchanged; this only unblocks the macOS crash suite while B1 itself is open.
Verification
The macOS
crash_safetyjobs on this pull request should pass with the entry matched, and the Linux and Windows runs are unaffected.