Repository navigation
Go helper regression suite times out in merge-group runs #5015
Description
🤖 Generated by the Agentic Engineer (interactive Claude Code session)
Evidence
Found by the merge-queue failure count in #4993.
- 3 failed merge-group runs between 2026-10-14 and 2026-10-15 failed in job
🔍 Detect Changes, step🧪 Validate the complete Go helper regression suite: the 10-minute Go test timeout ran out while a test waited for a metadata-proxy fixture to become ready. - Evidence basis: logs for all 3 runs.
- Examples: 38597082826, 38632802349, 38669600588.
Problem
A slow or flaky test fixture evicts candidates before they deploy.
Expected behaviour
The suite finishes well within its timeout on a normal runner, and a fixture that never becomes ready fails fast with its own message.
Acceptance criteria
- Find which test and fixture used the time, from the runs above.
- Make that fixture's readiness deterministic or bounded, so it fails fast with a clear message instead of using the whole suite timeout.
- The suite's merge-group duration is recorded before and after.
Size: small. Part of #4979.
Activity
devantler commentedon Oct 18, 2026
Additional bounded local observation at signed source acf88e6, using the repository-pinned Go 1.26.9 on macOS:
The complete repository suite failed only in the existing GHCR-auth fixture package after 592.439s. Thirteen test families reported their fixture command deadline, including the quiet-window controls, release-race controls and applied lease-fence mutation controls. Many late subtests had almost no execution time left: the harness bounds each command by the earlier of two minutes and the package deadline minus ten seconds. No timeout or assertion was changed.
This is not proof that the historical metadata-proxy failures have the same root cause, nor a hosted performance comparison. At this exact head, the complete hosted repository suite in CI39150213577 succeeded in 7m22s; the separate native retirement suite also passed. The enclosing workflow is still running.
Retain this issue's deterministic-readiness and before/after criteria. Future diagnosis should distinguish an individual fixture that never becomes ready from late-batch starvation of the package-wide budget; raising the package timeout would not establish either fix.
devantler commentedon Oct 18, 2026
The three cited failed runs contain two different failures, not three identical ten-minute timeouts:
Merged #4952 now installs, checksum-verifies and initializes the approved native tool before the suite, with five negative dependency controls. Merged #4902 separately bounds and reaps test-owned helper processes; it explicitly deferred runtime headroom to #4893. Those are existing delivered mitigations, not new fixes made by this comment.
Current exact-head hosted complete-suite jobs on #5052 and #5069 pass, but the broader local suite still exhausts fixture budgets. I am profiling the unchanged GHCR package under the existing #4893 scope rather than duplicating its implementation. No assertion or timeout has been relaxed. Keep this issue open until the remaining runtime cause and verification are actually resolved.