Stop the Document View lazy-body tests timing out under suite load - #417
Merged
Conversation
PR #416 split the Document View's markdown body behind a React.lazy import and updated its tests to await the result. Those awaits use testing-library's default 1000ms, which is enough when the file runs alone and not enough when the full suite runs: measured, two full-suite runs in three failed on `findByRole("heading")` or `findByText("still here")`. CI passed on #416 and on the merge, so this was already on main and would have started failing unrelated pull requests. The wait is long for a reason that only exists in the test environment. In a built bundle the lazy body is a prebuilt chunk; under vitest it is the FIRST transform of react-markdown plus six remark/rehype plugins, and 93 test files are competing for the worker pool while it happens. Nothing about the panel is slow. So the fix is to wait properly rather than to reach for fake timers or stub the import away - stubbing it would stop the tests exercising the thing #416 actually changed. One named constant at the four call sites that await the lazy body, with the measurement written down next to it. Verified both directions, because a longer timeout is exactly the kind of change that can quietly turn a test into a no-op: - five consecutive full-suite runs, 2,197 passed every time (was 2 failures in 3 runs before) - with the panel's body wired to never render, seven tests in the file fail and the suite goes red, so the wait has not made them vacuous Test plan: npm run check green. Python suite 3,285 passed / 20 skipped. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
Problem
This was already on main. PR #416 split the Document View's markdown body
behind a
React.lazyimport and updated its tests to await the result. Thoseawaits use testing-library's default 1000ms.
That is enough when the file runs alone. It is not enough when the full suite
runs:
DocumentViewPanel.test.tsxaloneCI passed on #416 and on the merge, so this would have started failing
unrelated pull requests rather than announcing itself.
Why the wait is long
Only in the test environment. In a built bundle the lazy body is a prebuilt
chunk; under vitest it is the first transform of react-markdown plus six
remark/rehype plugins, with 93 test files competing for the worker pool while
it happens. Nothing about the panel is slow.
Change
Wait properly, rather than reach for fake timers or stub the import away —
stubbing it would stop the tests exercising the thing #416 actually changed.
One named constant at the four call sites that await the lazy body, with the
measurement written down beside it.
Verified both directions
A longer timeout is exactly the kind of change that can quietly turn a test
into a no-op, so I checked it hasn't:
in 3 runs).
and the suite goes red — the wait has not made them vacuous.
Test plan
npm run checkgreen.🤖 Generated with Claude Code