[WIP] Investigate CI failure due to fuzz job cancellation#18344
Closed
[WIP] Investigate CI failure due to fuzz job cancellation#18344
Conversation
This was referenced Feb 25, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Thanks for assigning this issue to me. I'm starting to work on it and will keep this PR's description up to date as I form a plan and make progress.
Original prompt
This section details on the original issue you should resolve
<issue_title>[CI Failure Doctor] CI Failure Doctor - Run 22396700002: fuzz job cancelled by concurrency</issue_title>
<issue_description>### CI Failure Investigation - Run github/gh-aw#37830
Summary
The
fuzzjob for run 37830 (commit6867b8113f22940a4c3ebfffdfb1f99830ea1523) was terminated midway through the sequential fuzz targets because GitHub Actions’cancel-in-progressconcurrency guard kicked in when a newer CI workflow (run 37832) started on the same branch. The job never reported any test errors—only a cancellation message—so no defects were introduced by the commit itself.Failure Details
6867b8113f22940a4c3ebfffdfb1f99830ea1523Root Cause Analysis
The
fuzzjob defines aconcurrencygroup namedci-$\{\{ github.ref }}-fuzzwithcancel-in-progress: true, so when run 37832 (sha38ab34435fb7c33057d7a1935f21e490ba350e82) spun up at2026-02-25T12:26:52Z, GitHub Actions automatically cancelled the earlier run (37830) while it was still executingFuzzExpandLabelTriggerShorthand. The job logs end with##[error]The operation was canceled.at2026-02-25T12:28:07Z, and no fuzz test reported an unexpected failure prior to cancellation.Failed Jobs and Errors
Run fuzz testsstep):##[error]The operation was canceled.while executingFuzzExpandLabelTriggerShorthandafter completing 17 of the 24 queued fuzz targets. No assertions or module downloads failed.Investigation Findings
.github/workflows/ci.ymlintentionally prevents overlappingfuzzjobs by cancelling prior runs, so the cancellation is the expected behavior when another push lands onmain38ab3443…) started at12:26:52Z, run 37833 was cancelled shortly afterwards, and run 37834 is currently in progress, which is why the older run 37830 could not finishRecommended Actions
6867b8113f22940a4c3ebfffdfb1f99830ea1523if the fuzz results from that specific commit are still needed; the job had not failed, it was merely cancelled by the concurrency guard.main; otherwise the existingcancel-in-progresssetting is doing what it should and no code change is required.Prevention Strategies
Because the
fuzzjob runs a long series of sequential targets, it will always be cancelled when a newer push lands while it is still running; the best way to avoid these log entries is to let the latest run finish (no human action needed) or schedule the fuzz suite behind a manual gate. Re-running the workflow on the same commit will produce the full results.AI Team Self-Improvement
Before concluding that the
fuzzjob itself is broken, check for additional workflow runs in the same concurrency group and verify whether a##[error]The operation was canceled.message lines up withcancel-in-progressbeing triggered; that will prevent misclassifying expected cancellations as regressions.Historical Context
92baa35c…and run 37833 was itself cancelled, showing that the queue is active and newer pushes displace older buildsComments on the Issue (you are @copilot in this section)
🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.