Skip to content

use-testing halt-teardown test races its fixed 200ms start window under Node #335

Description

@taras

What is failing

an early caller-scope halt tears down the document and leased eval scope
(packages/testing/tests/use-testing.test.ts:214) fails intermittently under
Node:

expect(received).toBe(expected) // Object.is equality

Expected: false
Received: undefined

Observed once in a full pnpm test:node run under Node 22 (while a Deno suite
loaded the same machine), and once in 5 standalone runs of the file under Node
22 on an otherwise idle machine, on an unmodified checkout of main
(209bf218 plus only the #334 test-agent change, which does not touch this
package). CI has not caught it yet — it is the same load-sensitive class as
#332, found while verifying #334.

Why

The test writes globalThis.__useTestingHaltMarker = true inside the
document's eval block, sleep(200)s to "give the document time to start the
test and spawn its effect", then leaves the scope and asserts the marker is
false. When the document has not reached the eval block within 200ms — slow
tsx start, CPU contention — the marker is never set, the halt lands before the
spawn exists, and the assertion reads undefined instead of false.

The 200ms constant is a fixed start window racing a variable startup cost, the
same shape as #332's fixed 20s test timeout racing variable worker spawns. A
fix probably wants to wait for the marker to become true (bounded), halt,
then assert false — synchronizing on the observable state instead of a sleep.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    flakeIntermittent or timing-sensitive failure that can pass without a code change

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions