While running BuildTestEmbedded's full 565-script suite with './scripts/test.bash --test tests'

Reported (UTC): 2026-07-16 02:13

While running BuildTestEmbedded's full 565-script suite with './scripts/test.bash --test tests' (kompile-cli 0.0.65, community-kotlin-kompile-testrunner-jvm 0.0.2), the kompile test runner's TcpCommunicationHandler corrupted its Java ObjectInputStream at least twice while parallel BootstrapRunner JVMs were active. Exact first error: 'Unexpected error in TCP communication: invalid type code: 73' followed by 'java.io.StreamCorruptedException: invalid type code: 73' at ObjectInputStream.readTypeString/readClassDescriptor and TcpCommunicationHandler.handleCommunication(JvmUnitTestLauncher.kt:333). Exact second error: 'Unexpected error in TCP communication: class community.kotlin.kompile.testrunner.bootstrap.TcpMessage cannot be cast to class java.io.ObjectStreamClass' followed by ClassCastException at ObjectInputStream.readClassDesc/readArray and the same handler line. Impact: a test result or payload can be lost/misdecoded, making a full suite appear failed, incomplete, or non-deterministic even when individual product tests pass; rerunning a ~30-minute suite is expensive and does not make the transport safe. No product workaround was applied; I kept the original suite attached to capture its aggregate outcome and will rerun any missing scenario individually. Suggested durable fix: audit the parallel test launcher for multiple writers sharing one ObjectOutputStream/socket without a single framing/write lock, or multiple ObjectOutputStreams interleaving headers on one connection; serialize each complete TcpMessage under one connection-scoped mutex (including flush/reset) or give each worker an independently framed channel, and add a high-parallelism stress test that sends large heterogeneous TcpMessages and asserts every message decodes exactly once.

Production verification — 2026-07-17

Status: STILL EXISTS. Current production remains degraded rather than retired: buildtest.kotlin.build returned HTTP 200 but took 8.89 seconds, while the production host showed load average 60.59, CPU pressure near 90%, and the BuildTest JVM at about 1.8 GiB RSS.

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.