kompile-cli 0.0.65 local harness: legacy buildSimpleKotlinMavenArtifact fails with

Reported (UTC): 2026-07-15 15:33

kompile-cli 0.0.65 local harness: legacy buildSimpleKotlinMavenArtifact fails with 'PrivilegedBuildAssistantHolder instance should not be null' under concurrent full-suite test runs

What was being attempted: Running BuildTestServerService's full local test suite (43 tests, scripts/test.bash --test .) while preparing the per-droplet phaseTimestamps dependency-bump PR.

What went wrong: tests/fatJarJavaslangPackageIsComplete.kts failed because buildtest.server.buildFatJar() -> buildClientMaven() uses the LEGACY buildSimpleKotlinMavenArtifact API, which threw:

Error processing message visitMethodInsn: InvocationTargetException ...
Caused by: java.lang.IllegalStateException: PrivilegedBuildAssistantHolder instance should not be null, should have been set by trusted code prior to getInstance() being called
    at kompile.executionenvironment.bridge.interfaces.PrivilegedBuildAssistantHolder.getInstance(PrivilegedBuildAssistantHolder.java:14)
    at build.kotlin.jvm.JvmBuildRulesKt.buildSimpleKotlinMavenArtifact(JvmBuildRules.kt:1426)

beneath a 'kompile.BuildRuleExecutedEffect: build rule executed: buildtest.server.buildFatJar() (failed in ~73s)' line. The identical test PASSED when run solo (scripts/test.bash --test tests/fatJarJavaslangPackageIsComplete.kts), both on main and on the feature branch, and a subsequent full-suite rerun passed 43/43 ??? a transient concurrency artifact of the local harness, not a code issue.

Impact: A full-suite run reported 42/43 with a scary infra-flavored failure, requiring solo-rerun disambiguation before trusting the suite; agents that don't rerun solo may wrongly blame their diff or wrongly ship past a real failure.

Workaround used: Rerun the failing test solo to disambiguate, then rerun the full suite.

Suggested durable fix: In kompile's ExecutionEnvironment/JvmBuildScriptLauncher, ensure PrivilegedBuildAssistantHolder is set in every concurrently-launched execution JVM before legacy build rules call getInstance(). The *2 API path (buildSimpleKotlinMavenArtifact2/resolveDependencies2) did not exhibit the failure, so migrating remaining legacy call sites (e.g. BuildTestServerService build.kts buildClientMaven) to the *2 API probably also sidesteps it.

---

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.