fix(studio): the timeline viewport gate judges p95 over every measured scroll step - #4847
Merged
Merged
Conversation
Edit accuracy: 557 passing here, 557 on the base branchThe gate passes. |
miguel-heygen
force-pushed
the
fix/studio-viewport-gate-pooled-p95
branch
from
October 1, 2026 10:42
cbdd8d5 to
c48d70d
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The timeline viewport gate now judges scroll responsiveness on the p95 of every measured scroll step pooled, 315 steps over 5 runs at 63 per run, instead of requiring 4 of 5 runs to pass a p95 of 21 steps each. The 75 ms limit, the per-run long-task check and the memory check are unchanged.
Why
The rollback arm (row virtualization off, 1000 rows) failed intermittently on PRs that don't touch the timeline. Evidence pulled from the gate artifacts of 160 main jobs and the failing PR jobs:
Binomial model of the job failure rate, given the share q of scroll steps over 75 ms:
Tests
The gate and the fade-handle check now share one Chrome launcher (
launchStudioChromeinchrome-executable.mjs) instead of two copies of the same block.timeline-viewport-verdict.test.mjs(the verdict now lives intimeline-viewport-verdict.mjs, so it can be tested without Chrome): 16 slow steps of 315 fail and 15 pass; two slow steps in every run pass; one run slow throughout fails; a slow frame interval alone fails; a run short of samples throws instead of reading as fast; the gate fails when any one check fails. Each was run against a broken copy and fails: responsiveness dropped from the exit condition, the sample-count check removed, the verdict judged per run.timelineViewportBudgets.test.ts: the budget owner holds 63 samples per run.Gate sensitivity on a CI runner, with the do-not-merge draft test(studio): inject a 45 ms stall per timeline scroll step to prove the gate fails it #4848: this branch plus a fixed 45 ms main-thread stall on every timeline scroll step.
This branch on a hosted runner of the slow class (per-run p95 50 to 64 on the rollback arm): pooled p95 60.2 ms on the rollback arm and 33.2 ms on the virtualized arm. Both pass.
Added wall time per CI job: the rollback arm goes from 17 to 18 s to 34 s, the virtualized arm from 19 to 22 s to 32 s, and the gate step from 32 to 47 s to 69 s.
Before
The old rule failing the rollback arm on changes that don't touch the timeline (CI gate artifacts):
After
The pooled p95 on hosted runners: this branch passes, and the injected stall fails: