Repository · challenges
Kompile targeted tests reused a stale local build-rule artifact after source and Maven version
Reported (UTC): 2026-07-15 15:48
Kompile targeted tests reused a stale local build-rule artifact after source and Maven version changes.
What was being attempted: Run scripts/test.bash --test crossRunModuleBuildCacheReusesIdenticalInputs in a fresh BuildTestEmbedded checkout after adding ModuleBuildCache.kt, changing BuildTestEmbeddedService.kt, and bumping buildMaven coordinates from 0.0.298 to 0.0.299.
What went wrong: The source build completed successfully and the generated 0.0.299 JAR contained the new strings 'Published workspace module cache' and 'Workspace module cache is ready for shard fan-out', but repeated targeted test executions loaded the old 0.0.298 implementation. The end-to-end build logs still contained the removed line 'Prepared 184 byte workspace module cache for shard fan-out', and the assertion failed with 'Expected <1>, actual <2>'. The test catalog reported buildtest.embedded.buildMaven() as succeeding from cache in 1-8ms. This persisted even after editing the selected test and explicitly running scripts/build.bash buildtest.embedded.buildMaven.
Impact: Three targeted runs, each requiring the entire 545-script discovery/compile pass, produced false implementation failures and consumed substantial debugging time. Without inspecting bytecode strings and build logs, this could have led to changing correct production code to compensate for a stale test classpath.
Workaround used: Preserve and move /home/helena/.aibuildcaches/_code_workspace_BuildTestEmbedded-crossrun aside, then rerun the identical command with a fresh cache. The clean run compiled the 0.0.299 sources including ModuleBuildCache.kt and passed the scenario.
Suggested durable fix: Kompile's build-rule result/artifact dependency tracking should invalidate a cached @file:WithArtifact("buildtest.embedded.buildMaven()") result when the build rule's src directory contents or Maven coordinates change. The targeted test runner should also print the resolved artifact coordinate/path for local build-rule dependencies so a stale classpath is immediately visible.
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.