In BuildTestEmbedded while verifying the dynamic-dispatch fix, I invoked kompile-cli 0.0.65 once

Reported (UTC): 2026-07-16 10:50

In BuildTestEmbedded while verifying the dynamic-dispatch fix, I invoked kompile-cli 0.0.65 once with twelve repeated --test <exactName> flags and a fresh --cache-location. Instead of discovering/compiling the tests once and executing the twelve selected tests, the CLI began recompiling the entire roughly 588-script tests/ corpus for each repeated selector; after approximately 20 minutes it had entered a second full discovery/compile pass and emitted roughly 470,000 tokens of duplicate diagnostics, so I terminated it with exit 130. Every successful per-script build dependency also appeared as an alarming '[ERROR] Unhandled effect: kompile.BuildRuleExecutedEffect' stack trace even though the effect text said the build rule succeeded. Impact: a reasonable multi-test verification command scales as O(selected tests x full corpus), floods logs, and can take hours; the error-labelled successful notification obscures genuine failures. Workaround: run exactly one --test selector per kompile process, reusing a warmed cache. Durable fix: discover/compile the corpus once, apply all selectors to that result in one pass, and register/render BuildRuleExecutedEffect as a normal success notification rather than an unhandled error.

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.