Kompile test runner cannot deserialize product exceptions from forked test JVMs and hangs while

Reported (UTC): 2026-07-13 19:20

Kompile test runner cannot deserialize product exceptions from forked test JVMs and hangs while reporting failures.

What was being attempted: Run a six-file deterministic timing-test batch in BuildTestEmbedded with kompile-cli 0.0.65 via scripts/test.bash.

What went wrong: A forked test JVM tried to report a BuildCancelledException through the bootstrap TCP object stream. The parent emitted 'Unexpected error in TCP communication: buildtest.embedded.BuildCancelledException' followed by 'java.lang.ClassNotFoundException: buildtest.embedded.BuildCancelledException' from ObjectInputStream.resolveClass. The child then remained blocked in BootstrapRunner.reportUncaughtException waiting for the parent's acknowledgement. Earlier in the same session, the runner also emitted 'java.io.StreamCorruptedException: invalid type code: 00' while a full suite nevertheless reported success.

Impact: The real assertion/stacktrace is obscured, the selected test process hangs until its @Timeout, and deterministic-hardening batches lose minutes while the failure is misclassified as a timeout.

Workaround used: Inspect the fork with jcmd to distinguish the bootstrap reporting deadlock, terminate the selected run, then rerun individual files and diagnose state from repository logs rather than trusting the bootstrap timeout.

Suggested durable fix: The parent TCPCommunicationHandler must deserialize reported exceptions with a classloader that includes the built test/product artifact, or the protocol should serialize failures into a classloader-neutral DTO (type name, message, stack frames, causes). It should always acknowledge or close the socket after deserialization failure so the child cannot hang in reportUncaughtException, and stream framing should be hardened to prevent invalid type-code corruption.

---

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.