Problem
The exact concurrent verification battery can leave the Deno browser bundler output in a test-owned scratch directory after the Effection scope has torn down.
Observed on commit b82121c while verifying PR #415 on macOS arm64 with Deno 2.9.5:
deno task verify
verifying 9 commands concurrently (site/ unchanged since origin/main), 20m deadline each
ok vendor 4.5s
ok lint 2.7s
ok check 1.6s
FAILED test 792.8s (exit 1)
ok check:jsr 1.5s
ok tsc 22.9s
FAILED test:node 271.8s (exit 1)
ok test:bun 652.5s
ok docs 20.3s
build-web-client ... leaves nothing behind when a build fails
Expected: []
Received: ["2361ba29aac95f1f.js"]
at scripts/tests/build-web-client.test.ts:237:37
FAILED | 424 passed (2971 steps) | 1 failed (1 step) (13m11s)
The failure is in the test that starts buildWebClient({ scratch }), ends its scoped owner with the check that started the build failed, and then requires the scratch directory to be empty. The lingering hash-named JavaScript file is the real deno bundle output.
The identical committed revision immediately passed the isolated Deno file:
deno task test scripts/tests/build-web-client.test.ts
ok | 3 passed (24 steps) | 0 failed (14s)
leaves nothing behind when a build fails ... ok (57ms)
The same verifier invocation also reported a Node runner failure with no second-failure detail. The identical revision then passed pnpm test:node alone with 2,708/2,708 tests in 200.3s; that phantom runtime failure is recorded on #275.
Concurrency evidence
- Failure: the full nine-command battery, with Deno, Node, Bun, builds, typechecks, and publishability running together.
- Pass: the identical Deno test file in isolation without a code change.
- Pass: the identical full Node suite in isolation without a code change.
- The branch changes only Workspace coordination source, tests, and specifications; it does not change the browser build or process adapter.
Acceptance
- The exact concurrent
deno task verify battery repeatedly leaves no hash-named bundle output after either interrupted-build test.
- Scope teardown joins or terminates the real bundler before scratch cleanup completes.
- The regression uses lifecycle barriers or process ownership, not sleeps, polling, retries, a longer verifier deadline, serialization, or an exclusion.
- The isolated and concurrent Deno/Node/Bun suites remain green.
Problem
The exact concurrent verification battery can leave the Deno browser bundler output in a test-owned scratch directory after the Effection scope has torn down.
Observed on commit
b82121cwhile verifying PR #415 on macOS arm64 with Deno 2.9.5:The failure is in the test that starts
buildWebClient({ scratch }), ends its scoped owner withthe check that started the build failed, and then requires the scratch directory to be empty. The lingering hash-named JavaScript file is the realdeno bundleoutput.The identical committed revision immediately passed the isolated Deno file:
The same verifier invocation also reported a Node runner failure with no second-failure detail. The identical revision then passed
pnpm test:nodealone with 2,708/2,708 tests in 200.3s; that phantom runtime failure is recorded on #275.Concurrency evidence
Acceptance
deno task verifybattery repeatedly leaves no hash-named bundle output after either interrupted-build test.