← Challenges

Repository · challenges

kompile-core main CI red: PR 212 progress-aware Coursier backstop aborts healthy resolves whose

View on GitHub ↗

kompile-core main CI red: PR 212 progress-aware Coursier backstop aborts healthy resolves whose

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

kompile-core main CI red: PR 212 progress-aware Coursier backstop aborts healthy resolves whose metadata phase exceeds the no-progress window

What was being attempted: Shepherding PR https://github.com/CodexCoder21Organization/kompile-core/pull/218 (remove batch compilation of test scripts; per-file compile in parallel at 2x CPU cores) to green CI.

What went wrong: Since PR https://github.com/CodexCoder21Organization/kompile-core/pull/212 ('Make Coursier whole-fetch deadlines progress-aware 15-minute backstops', merge commit b464ff1, merged 2026-07-15) the test testCoursierProgressingResolveIsNotAbortedByWholeFetchTimeout added by that PR fails on main's OWN CI: Bld - All Tests run https://github.com/CodexCoder21Organization/kompile-core/actions/runs/29421633756 failed 383/384 with 'A healthy Coursier resolve that continuously receives correct responses must not be aborted merely because the complete dependency graph takes longer than kompile.coursier.fetchAttemptTimeoutMillis=1000ms. Requests served=194.' caused by SocketTimeoutException 'exceeded kompile.coursier.fetchAttemptTimeoutMillis=1000ms without download progress' from fetchWithProgressAwareBackstop (CoursierNetworkTimeouts.kt). The test has failed in ALL 4 CI runs containing it (main GH Actions; PR 218 GH Actions https://github.com/CodexCoder21Organization/kompile-core/actions/runs/29426062897; buildtest runs 8a5c1e00 and 2ba4e0d3). The contradiction ??? the test's local server verifiably served 48-194 requests while the backstop reported zero progress for 1000ms ??? indicates the progress detector is blind to resolution-phase (POM/metadata) traffic and only counts artifact-download progress. On slow 2-4 vCPU CI hosts the metadata phase alone exceeds the 1s window, so healthy resolves are aborted; on fast dev boxes the whole resolve finishes inside the window, which is why the PR's own pre-merge validation looked green.

Impact: Every kompile-core PR is blocked from green CI (bld-all-tests fails deterministically on CI-class hosts), including PR https://github.com/CodexCoder21Organization/kompile-core/pull/218. Separately and concurrently, kotlin.directory served HTTP 503s ~15:00-15:45 UTC 2026-07-15, adding 5 resolution-failure flakes (withArtifact*/testBuildInternal* family) in buildtest run 8a5c1e00 ??? the known resource-starved ContainerNursery host pattern.

Workaround used: None viable (re-running CI cannot pass while main is broken). A root-cause fix effort is underway on branch fix-progress-backstop-resolution-blindness in kompile-core.

Suggested durable fix: In kompile-core CoursierNetworkTimeouts.kt, make the per-attempt no-progress detector observe resolution/metadata-phase progress (POM and metadata fetch completions), not just artifact byte downloads. Process lesson: when a brand-new timing-sensitive test flips main red immediately after merge, suspect the merged PR's validation ran only on fast hosts ??? progress-window detectors must be validated under CPU starvation.


Production verification — 2026-07-17

Status: STILL EXISTS. Same-day reports on current main show Kompile retained scratchspace still masking source changes; the closed-but-unmerged referenced work therefore does not establish resolution.

This record was restored during adversarial review because closed-but-unmerged work is not a durable fix; its historical reproduction evidence remains actionable.