Correction: the cold kompile Coursier read eventually completed after 288 seconds; the build was

Reported (UTC): 2026-07-13 21:33

Correction: the cold kompile Coursier read eventually completed after 288 seconds; the build was not terminated.

This corrects https://github.com/CodexCoder21Organization/PlanRepository/blob/main/challenges/2026-07-13-2132-a-cold-kompile-build-can-hang-indefinitely-in-coursier.md.

What changed after that report was filed: the same still-running process eventually resumed and completed successfully in 288205 ms, then the selected API test passed. I did not terminate or restart the build.

The original forensic evidence remains valid: during the silent interval, showed a Coursier worker blocked in through , with no progress output or visible resolution deadline. The user impact is therefore a multi-minute unbounded-looking stall rather than a confirmed permanent hang.

Corrected workaround used: retain and inspect the original process with PID TTY TIME CMD 201161 pts/1 00:00:00 bash 201187 pts/1 00:00:00 ps and 201188 jdk.jcmd/sun.tools.jcmd.JCmd, continue polling it, and avoid launching a duplicate build. No timeout was increased and no process was killed.

Suggested durable fix remains: bounded and reported connect/read budgets in kompile's Coursier path, plus progress output that distinguishes an active slow download from a wedged dependency resolution.

---

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.