← Challenges

Repository · challenges

BuildTestEmbedded local tests silently reused an old Maven artifact after source changes.

View on GitHub ↗

BuildTestEmbedded local tests silently reused an old Maven artifact after source changes.

Reported (UTC): 2026-07-15 17:11

BuildTestEmbedded local tests silently reused an old Maven artifact after source changes.

What was being attempted: Run the six new TDD regression scenarios after implementing a deleteBuildRun lease guard and tombstone behavior in BuildTestEmbedded.

What went wrong: After src/buildtest/embedded/BuildTestEmbeddedService.kt changed, scripts/test.bash reported repeated 'build rule executed: buildtest.embedded.buildMaven() (succeeded in 1ms)' messages and all six tests produced byte-for-byte the original-HEAD failures: fresh deletion 'Expected an exception of class java.lang.IllegalStateException to be thrown, but was completed successfully' and tombstone reads returned null. The test @WithArtifact buildtest.embedded.buildMaven() had reused the existing 0.0.298 artifact instead of recompiling changed source.

Impact: A post-fix test run appeared to prove the implementation had no effect, wasting a full roughly nine-minute test-catalog compile and creating a serious false-negative/false-positive risk for strict TDD work.

Workaround used: Bump the required build.kts Maven coordinate from buildtest.embedded:buildtest-embedded:0.0.298 to 0.0.299 before rerunning tests, which invalidates the artifact cache and compiles the changed source.

Suggested durable fix: kompile buildMaven artifact caching should include the source/build-rule input hash or scripts/test.bash should detect a dirty source tree whose current coordinate artifact predates its inputs, rebuild it, and print an explicit cache-hit provenance line rather than silently executing stale code.


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.