test/bridge.test.ts > BridgeClient > cancels a hung bridge tree and fails mutation closed fails roughly half of local runs on Windows:
AssertionError: promise resolved "undefined" instead of rejecting
❯ test/bridge.test.ts:551:37
549| expect(response.message).toContain("timed out");
550| await new Promise((done) => setTimeout(done, 1_200));
551| await expect(access(sentinel)).rejects.toThrow();
The test asserts the cancellation removed a sentinel file, but waits a fixed
1,200 ms for the process-tree teardown to get there. On a loaded Windows box
that wall clock is not always enough, so access(sentinel) still resolves and
the assertion reads the delay as a teardown failure.
Measured 2026-08-01 on sprint/portable-release-and-protected-state, which
touches nothing under plugins/ca-pi/: 6 consecutive direct runs of the three
PI-SEC-ADVERSARIAL suites gave 4 pass / 2 fail; a further 4 gave 1 pass /
3 fail. It surfaces through test_pi_security.py as a red PI-SEC-ADVERSARIAL
row, which is how it was found.
CI has not gone red on it so far (run 30691314813 reported PI-SEC-ADVERSARIAL
green), so this is filed rather than fixed inline.
Fix direction: replace the fixed sleep with a poll-until-gone loop bounded
by a generous timeout, so the test measures whether teardown happens rather
than whether it happens inside an arbitrary 1.2 s. Same shape as the other two
open flakes, #504 and #535.
test/bridge.test.ts > BridgeClient > cancels a hung bridge tree and fails mutation closedfails roughly half of local runs on Windows:The test asserts the cancellation removed a sentinel file, but waits a fixed
1,200 ms for the process-tree teardown to get there. On a loaded Windows box
that wall clock is not always enough, so
access(sentinel)still resolves andthe assertion reads the delay as a teardown failure.
Measured 2026-08-01 on
sprint/portable-release-and-protected-state, whichtouches nothing under
plugins/ca-pi/: 6 consecutive direct runs of the threePI-SEC-ADVERSARIALsuites gave 4 pass / 2 fail; a further 4 gave 1 pass /3 fail. It surfaces through
test_pi_security.pyas a redPI-SEC-ADVERSARIALrow, which is how it was found.
CI has not gone red on it so far (run 30691314813 reported
PI-SEC-ADVERSARIALgreen), so this is filed rather than fixed inline.
Fix direction: replace the fixed sleep with a poll-until-gone loop bounded
by a generous timeout, so the test measures whether teardown happens rather
than whether it happens inside an arbitrary 1.2 s. Same shape as the other two
open flakes, #504 and #535.