[CI Failure Doctor] 🏥 CI Failure Investigation - Run #34215 #14343
Description
Summary
The workflow terminated because the fuzz job was canceled when a newer workflow run (34216) grabbed the ci-${{ github.ref }}-fuzz concurrency slot while the previous run was still executing. No unexpected test failures occurred in run 34215.
Failure Details
Root Cause Analysis
The fuzz job defines concurrency.group: ci-${{ github.ref }}-fuzz with cancel-in-progress: true. When run 34216 began at 2026-02-07T13:16:22Z, GitHub automatically canceled the still-running fuzz job from run 34215 to enforce the concurrency guard. The log for job 62844076215 records ##[error]The operation was canceled. shortly after FuzzTemplateRendering started and before any test failures.
Failed Jobs and Errors
fuzz(job 62844076215): canceled at 2026-02-07T13:16:36Z (##[error]The operation was canceled.)logs-token-check: controlled byif: false, so the skip is intentional and unrelated to this failure.
Investigation Findings
- Run 34215 completed at 2026-02-07T13:16:39Z without producing test failures aside from the cancellation.
- Run 34216 (ID 21780683163), which started at 2026-02-07T13:16:22Z, took over the fuzz run and thus triggered the concurrency cancellation of the previous run.
- Attempts to push multiple commits back-to-back (see runs 34214 and 34216) repeatedly hit this cancellation because the newest run always cancels the earlier one to keep only one fuzz job running.
Recommended Actions
- Re-run the workflow for commit e64069c if a successful fuzz result is required, and avoid pushing another commit until the job finishes so it keeps the concurrency slot.
- If repeatedly canceled runs are problematic, consider whether the
cancel-in-progressbehavior should be relaxed (e.g., remove the concurrency guard or add a wait before triggering another run) so that each push has a chance to finish.
Prevention Strategies
- Avoid making rapid succession pushes to
mainwhile a fuzz job is running; wait for the currently running job to finish before pushing a subsequent commit. - Document the concurrency guard in future CI failure triage notes so cancelled jobs are not mistaken for code regressions.
AI Team Self-Improvement
When analyzing runs that use cancel-in-progress concurrency, always look for newer runs in the same group and the log line The operation was canceled. before declaring the failure as code-related, then note that the run was canceled to avoid chasing phantom bugs.
Historical Context
Runs 34214 and 34216 also recorded the fuzz job being canceled when a newer run started, so this is a recurring pattern whenever commits land in rapid succession on main.
AI generated by CI Failure Doctor
To add this workflow in your repository, run
gh aw add githubnext/agentics/workflows/ci-doctor.md@ea350161ad5dcc9624cf510f134c6a9e39a6f94d. See usage guide.
- expires on Feb 8, 2026, 1:21 PM UTC