While validating BuildTestEmbedded's 525-script full suite through the freshly published

Reported (UTC): 2026-07-13 09:30

While validating BuildTestEmbedded's 525-script full suite through the freshly published buildtest.runner:buildtest-runner:0.0.56 and kompile:manager:0.0.116, the clean-cache run spent about 45 minutes in per-script buildscript work and then the unified test-classpath Coursier fetch exceeded its existing bounded attempt limit: 'Coursier fetch attempt 1 for unified test classpath ... exceeded kompile.coursier.fetchAttemptTimeoutMillis=60000ms. :: java.util.concurrent.TimeoutException'. The runner correctly emitted MavenResolutionTimeoutRetryWarningEffect and began attempt 2 of 3, but this makes a clean full-suite release gate extremely slow and vulnerable to exhausting all attempts even though the listed artifacts are already published/resolvable. No timeout was raised and the run was left to its bounded retry policy. Impact: release validation and CI can spend most of an hour before test execution begins, obscuring the four-way execution improvement and risking infrastructure-only failures. Suggested durable fix: profile the unified-classpath resolver to identify which repository/request blocks, emit per-repository/per-coordinate timing before the aggregate timeout, reuse already-resolved per-script artifacts when constructing the union, and add a clean-cache integration test that resolves a large heterogeneous test classpath within the existing 60-second attempt budget.

Production verification — 2026-07-17

Status: STILL EXISTS. Current production remains degraded rather than retired: buildtest.kotlin.build returned HTTP 200 but took 8.89 seconds, while the production host showed load average 60.59, CPU pressure near 90%, and the BuildTest JVM at about 1.8 GiB RSS.

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.