test/shards.test.ts retry-alone tests pin their shard count: they hold every release on the runner #2729

The retry-alone tests in test/shards.test.ts now pin their environment, but I couldn't reproduce the runner failure here, so I don't know that this fixes it. The type check didn't run: bunx tsc --noEmit failed with a read-only tempdir error. The edit is test-only and uses the same types as the code beside it.

What changed

• The a failing file is run once more alone describe block now builds one env for the runner it spawns. It sets FORGE_CHECK_SHARDS=2 and FORGE_CELL_CPUS=4, so the shard count and the CPU cap no longer follow the host.
• The env also drops every other FORGE_CHECK_* variable the surrounding gate might export. FORGE_CHECK_SHARD_INDEX and FORGE_CHECK_SHARD_TOTAL would otherwise turn the spawned run into a slice of a bigger gate.

Why I'm unsure it's the cause

• The test already passed FORGE_CHECK_SHARDS=2, and that overrides the CPU-based count. On this machine the split is already shard-filler alone, then shard-poison, shard-victim, shard-broken. That is the same split the issue reports from the runner.
• So I couldn't find a host-dependent shard count in this test. A leaked FORGE_CHECK_SHARD_* variable is my best guess for what differs on the runner, but I haven't confirmed it.
• The fix is a guard against that guess. If the forge's check still fails on the runner, the log of the spawned run will say what differs.

Tests

• I ran the four retry-alone tests with FORGE_CELL_CPUS=2 and FORGE_CELL_CPUS=16, with FORGE_CHECK_SHARD_INDEX=1 and FORGE_CHECK_SHARD_TOTAL=7 also exported. All four passed both times (4 pass, 0 fail).
• I didn't run the whole bun test suite here.

What I left out

• I didn't change scripts/test-shards.ts or scripts/shards.ts; the runner's behaviour is unchanged.

Closes #2726

The retry-alone tests in test/shards.test.ts now pin their environment, but I couldn't reproduce the runner failure here, so I don't know that this fixes it. The type check didn't run: bunx tsc --noEmit failed with a read-only tempdir error. The edit is test-only and uses the same types as the code beside it.

What changed

• The a failing file is run once more alone describe block now builds one env for the runner it spawns. It sets FORGE_CHECK_SHARDS=2 and FORGE_CELL_CPUS=4, so the shard count and the CPU cap no longer follow the host.
• The env also drops every other FORGE_CHECK_* variable the surrounding gate might export. FORGE_CHECK_SHARD_INDEX and FORGE_CHECK_SHARD_TOTAL would otherwise turn the spawned run into a slice of a bigger gate.

Why I'm unsure it's the cause

• The test already passed FORGE_CHECK_SHARDS=2, and that overrides the CPU-based count. On this machine the split is already shard-filler alone, then shard-poison, shard-victim, shard-broken. That is the same split the issue reports from the runner.
• So I couldn't find a host-dependent shard count in this test. A leaked FORGE_CHECK_SHARD_* variable is my best guess for what differs on the runner, but I haven't confirmed it.
• The fix is a guard against that guess. If the forge's check still fails on the runner, the log of the spawned run will say what differs.

Tests

• I ran the four retry-alone tests with FORGE_CELL_CPUS=2 and FORGE_CELL_CPUS=16, with FORGE_CHECK_SHARD_INDEX=1 and FORGE_CHECK_SHARD_TOTAL=7 also exported. All four passed both times (4 pass, 0 fail).
• I didn't run the whole bun test suite here.

What I left out

• I didn't change scripts/test-shards.ts or scripts/shards.ts; the runner's behaviour is unchanged.