While validating a one-line BuildTestRunner version-pin change in a fresh BuildTestEmbedded

Reported (UTC): 2026-07-13 08:15

While validating a one-line BuildTestRunner version-pin change in a fresh BuildTestEmbedded checkout, the required full local command HOME=/tmp/buildtest-embedded-parallel-fixed-home scripts/test.bash --test . used kompile-cli:0.0.65 and corrupted its parent/child Java serialization stream under parallel execution. Exact errors included java.io.StreamCorruptedException: invalid type code: 00, java.io.StreamCorruptedException: invalid handle value: 7870007E, ClassNotFoundException: buildtest.embedded.BuildCancelledException while deserializing a child failure, and ClassCastException: cannot assign instance of community.kotlin.kompile.testrunner.bootstrap.TcpMessage to field java.lang.Throwable.suppressedExceptions. The run then reported renewBuildLeaseJoinTimeoutStillAdvances timed out after 30000ms, with 527/528 completed and five of 533 never dispatched. The allegedly timed-out test passed in isolation immediately using the same source and cache, showing the production/test behavior was not the cause; the outer harness transport made the full-suite result unreliable. This blocks trustworthy local release gating and recreates transport defects already addressed by newer testrunner-jvm/bootstrap releases. Workaround: rerun the affected test in isolation and validate the complete suite through BuildTestRunner 0.0.55 / kompile:manager 0.0.115, which carries the transport-safe launcher/bootstrap chain. Durable fix: update scripts/test.bash or the kompile-cli coordinate it launches so full suites use the current transport-safe testrunner-jvm/bootstrap pair, add a many-concurrent-child stress regression, and make a stream-corruption error fail fast with the affected child test identity instead of allowing later unrelated timeout attribution.

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.