Skip to content

subprocess-stub vitest project: members and kill criterion (#1781 A4) #1823

Description

@thymikee

The subprocess-stub Vitest project (vitest.config.ts) runs its members serialized
(fileParallelism: false, maxWorkers: 1) so only one file at a time spawns real stub binaries.
This issue is the live tracker for its membership and for deleting it.

Members (3)

file why it spawns for real measured
src/__tests__/client-metro.test.ts stubs npx plus the package managers and spawns a real Metro dev server per case; each case waits a real readiness poll 4.7s CI / 5.7s local, 20 tests, 567-922ms per case
scripts/fuzz/harness.test.ts the SUT is the subprocess watchdog: execFileSync(process.execPath, …) per case, one target hangs on purpose (#1414) 13.2-14.0s CI / 16.8s local, 10 tests; worst case 4.4s
scripts/fuzz/corpus-replay.test.ts replays the corpus through the same worker watchdog, waiting its per-case budget (CASE_TIMEOUT_MS = 5_000) 2.2-2.4s CI / 1.1s local, 9 tests

Three former members were dropped in the same PR: src/platforms/android/__tests__/app-deployment.test.ts (31ms in CI), src/__tests__/platform-runtime-runtime-hints.test.ts (212ms), src/platforms/apple/core/__tests__/apps.test.ts (277ms, already vi.mocks the exec seam). At those durations there is nothing to serialize.

Deletion test (kill criterion)

If the three members run un-serialized in the default pool for 20 consecutive CI runs with no timeout-shaped failure, the project has no member that needs it — delete the project and fold the three files back into unit-core.

To run the experiment: drop SUBPROCESS_STUB_TESTS from unit-core's exclude and delete the subprocess-stub project block; the files then run in the default forks pool. Revert if a timeout-shaped failure appears.

Lane accounting

  • Catches: CPU contention starving real stub-binary spawns past an internal budget, for the files that genuinely spawn.
  • Evidence: the config comment cites the pre-split android/index.test.ts aggregation. process.env isolation — the other stated motive — is already delivered by pool: forks + isolate: true on every project, so serialization is only about CPU contention.
  • Cost: ~15 lines of config; ~0 added CI wall clock (it runs as a concurrent project alongside unit-core, which is the 296s critical path); ~25-37s serialized chain locally.
  • Kill-criterion: the deletion test above.

Context: the contention retry was removed

The enumerated single-retry policy that used to share this file list (scripts/lib/contention-retry*.ts, #1419) was deleted in the PR that filed this issue (#1781 A4). It fired 0 times since it landed on 2026-07-29: 0 of 234 sampled Coverage-job lane envelopes (2026-08-11 → 2026-08-18) had retryCount > 0, and none of 17 recent failed runs was retried (5 refused "a failure landed outside the enumerated retry list", 4 refused "unhandled error"). It cost ~1,454 LOC. All three trackers its entries pointed at (#1098, #1414, #1419) are closed, which is why this issue exists: the stub project needed a live tracker of its own.

Umbrella: #1781 (item A4).

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions