Kompile buildMaven reused a stale artifact after local source API changes.

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

What was being attempted: while adding a deterministic regression for a stalled BuildTestEmbedded droplet-service RPC, I changed the public createDropletViaAsync signature in src/buildtest/embedded/DropletManager.kt, rebased with git rebase --autostash origin/main as required, and ran scripts/test.bash --test ./tests/createDropletAsyncStallIsBounded.kts.

What went wrong: the build logged "buildMaven() succeeded in 12ms", but the downstream test compiler then failed with "error: cannot find a parameter with this name: clock" and "error: cannot find a parameter with this name: rpcCallTimeoutMs" even though both named parameters were present in the working-tree source. The Maven build rule had reused a cached artifact produced before the dirty source edit.

Impact: source-level tests can compile against an obsolete implementation, producing misleading compiler errors and preventing fail-first/fix verification unless the developer recognizes the cache mismatch.

Workaround used: increment the local Maven artifact version in build.kts so the build rule cannot reuse the prior coordinate, then rebuild after the mandatory rebase.

Suggested durable fix: include the complete input source content (including dirty working-tree changes) in the buildMaven/build-rule result cache key, or validate that a cached artifact fingerprint matches the current source tree before reporting success.

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.