Summary
PR #4876 correctly stops the Windows batch runner from queueing against its own previous batch by setting OCX_TEST_NO_QUEUE=1 on the Test in fresh-process batches step. However, the only Windows-only regression that proves nested Bun processes inherit and enforce the live test-run lock is guarded by the opposite condition:
test.if(process.platform === "win32" && process.env[TEST_RUN_NO_QUEUE_ENV] !== "1")(
"nested Windows Bun tests inherit the acquired live lock and refuse an incomplete capability",
// ...
)
On current dev (6304a94c03), that test is therefore skipped in the exact Windows step whose lock behavior it is meant to protect.
Current evidence
.github/workflows/ci.yml sets OCX_TEST_NO_QUEUE: "1" for the Windows fresh-process batch step.tests/ci-workflows/test-runner.test.ts skips the nested live-lock test whenever that variable is 1.- The same test is Windows-only, so Linux/macOS shards cannot cover it.
- The ordinary no-queue unit test only proves that
resolveWrappedTestRunLockPath() returns undefined; it does not prove the nested-process capability/incomplete-capability behavior exercised by the skipped integration.
Impact
A regression in nested Windows lock inheritance, membership creation, preload/home guard propagation, or incomplete-capability refusal can pass the main Windows suite silently. This is a test-coverage hole, not a claim that production service behavior is currently broken.
Required correction
Keep the outer batch step's no-queue behavior from #4876, but run the nested lock regression in a controlled child environment that explicitly supplies an acquired test lock and removes OCX_TEST_NO_QUEUE only for that fixture. The test should prove:
- the child inherits the same lock path, run id, and token;
- the child member receipt exists;
- preload and the live-home guard are armed;
- an incomplete inherited capability is refused; and
- the parent owner receipt is unchanged.
The corrected test must execute on hosted Windows CI and must not reintroduce queueing between the outer six-file batches.
Regression origin
Introduced by the interaction between #4851's fresh-process batching and #4876's step-wide no-queue environment. #4876 remains directionally correct; this issue tracks restoring the coverage it unintentionally disabled.
Summary
PR #4876 correctly stops the Windows batch runner from queueing against its own previous batch by setting
OCX_TEST_NO_QUEUE=1on the Test in fresh-process batches step. However, the only Windows-only regression that proves nested Bun processes inherit and enforce the live test-run lock is guarded by the opposite condition:On current
dev(6304a94c03), that test is therefore skipped in the exact Windows step whose lock behavior it is meant to protect.Current evidence
.github/workflows/ci.ymlsetsOCX_TEST_NO_QUEUE: "1"for the Windows fresh-process batch step.tests/ci-workflows/test-runner.test.tsskips the nested live-lock test whenever that variable is1.resolveWrappedTestRunLockPath()returnsundefined; it does not prove the nested-process capability/incomplete-capability behavior exercised by the skipped integration.Impact
A regression in nested Windows lock inheritance, membership creation, preload/home guard propagation, or incomplete-capability refusal can pass the main Windows suite silently. This is a test-coverage hole, not a claim that production service behavior is currently broken.
Required correction
Keep the outer batch step's no-queue behavior from #4876, but run the nested lock regression in a controlled child environment that explicitly supplies an acquired test lock and removes
OCX_TEST_NO_QUEUEonly for that fixture. The test should prove:The corrected test must execute on hosted Windows CI and must not reintroduce queueing between the outer six-file batches.
Regression origin
Introduced by the interaction between #4851's fresh-process batching and #4876's step-wide no-queue environment. #4876 remains directionally correct; this issue tracks restoring the coverage it unintentionally disabled.