Skip to content

Stop the Document View lazy-body tests timing out under suite load - #417

Merged
dovvnloading merged 1 commit into
mainfrom
fix/document-view-lazy-test-flake
Sep 5, 2026
Merged

Stop the Document View lazy-body tests timing out under suite load#417
dovvnloading merged 1 commit into
mainfrom
fix/document-view-lazy-test-flake

Conversation

@dovvnloading

Copy link
Copy Markdown
Owner

Problem

This was already on main. 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.

That is enough when the file runs alone. It is not enough when the full suite
runs:

result
DocumentViewPanel.test.tsx alone 45 passed
Full suite, 3 runs 2 failed

CI 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:

  • Five consecutive full-suite runs: 2,197 passed every time (was 2 failures
    in 3 runs).
  • With the panel's body wired to never render, seven tests in the file fail
    and the suite goes red — the wait has not made them vacuous.

Test plan

  • npm run check green.
  • Python suite: 3,285 passed, 20 skipped.

🤖 Generated with Claude Code

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>
@dovvnloading
dovvnloading merged commit 81ea12f into main Sep 5, 2026
5 checks passed
@dovvnloading
dovvnloading deleted the fix/document-view-lazy-test-flake branch September 5, 2026 04:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant