Repository navigation
Count chart redraws instead of timing the resize check (fix #495) - #497
Merged
Merged
Conversation
stephaniehobson
changed the title
The 1000 ms long-task budget failed on slow CI runners because the resize itself costs more there, and the traced retry slowed each step past the resize debounce so every chart redrew at every width. Counting line d writes checks the same two regressions without depending on runner speed.
stephaniehobson
force-pushed
the
495--resize-timing-flake
branch
from
November 10, 2026 15:41
31e4724 to
b47c51f
Compare
stephaniehobson
marked this pull request as ready for review
November 10, 2026 15:52
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.
One-line summary
Make the hardware resize check count chart redraws instead of timing them, so it stops failing on slow CI runners.
Significant changes and points to review
resize.spec.jsno longer compares long tasks against a 1000 ms budget. It counts writes to each chart'spath.mg-main-linedattributes during the resize sequence, and expects one write per line per chart: a single redraw, with no animation. That checks the same two regressions as before (lines animating on resize, and charts redrawing on every resize event) without depending on how fast the runner is.ChartContainer's 150 ms debounce, so every chart redrew at all seven widths. That's where the 6946 ms failure came from.Issue / Bugzilla link
Fixes #495
Testing
transition_on_update: falseredraw insrc/components/views/MetricsGraphics.jsxand runnpx playwright test fixtures/resize.spec.js --project=chromium --retries=0. It fails with 2 writes per line.setTimeoutdebounce inChartContainer._onResizewith a directthis._setChartSize()call and run the same command. It fails with 7 writes per line.