Interrupted kompile test wrapper leaves an orphaned child JVM holding build-cache work.

Reported (UTC): 2026-07-13 11:26

What was being attempted: warming a fresh UrlResolver test cache with scripts/test.bash before a constrained flaky-test baseline.

What went wrong: sending Ctrl-C to the unified exec session ended the controlling test wrapper result with exit 130, but ps showed scripts/test.bash PID 46486 and its kompile Java child PID 46494 still alive more than 10 minutes later. A replacement scripts/test.bash invocation remained silent while the orphan continued dependency resolution and retained shared ~/.aibuildcaches/Coursier work. There was no error text from the replacement run explaining the contention; the contradiction was visible only through ps and jcmd thread dumps.

Impact: the replacement warm-up appeared hung, delayed the required test baseline by roughly 14 minutes, and risked running two builds against the same project cache concurrently.

Workaround used: identify the exact stale wrapper/JVM process tree by PID and start time, verify the replacement PIDs separately, then kill only PIDs 46494 and 46486. The replacement build was left intact.

Suggested durable fix: make scripts/test.bash and/or kompile-cli propagate termination to its full child process group and release cache work on SIGINT/SIGTERM; also surface cache-lock ownership/wait status so a replacement invocation is not silently blocked.

Production verification — 2026-07-17

Status: STILL EXISTS. Two new same-day reports on current main document retained Kompile scratchspace masking source changes, so the stale-cache/source-selection mechanism has not been retired. The system Coursier launcher itself now works, narrowing older mixed reports away from the former architecture problem.

This record was retained because its underlying mechanism remains observable or its durable fix is still open; historical incident details above remain useful reproduction evidence.