Autofix pushes cancel in-progress review-pr, creating a self-reinforcing loop on bot-authored PRs #8888

Activity

1. yiliang114

   added

   status/needs-triageIssue needs to be triaged and labeledIssue needs to be triaged and labeled

   type/bugSomething isn't working as expectedSomething isn't working as expected

   on Aug 10, 2026
2. doudouOUC commented on Aug 10, 2026

   

   doudouOUC

   on Aug 10, 2026

   Collaborator

   More actions

   Confirmed against current main — the analysis matches what the workflows actually do, and there are two reinforcing mechanisms (one on each side) worth adding.

   Root cause (verified)

   .github/workflows/qwen-code-pr-review.yml, concurrency block (lines 51–59 on main):

   concurrency:
     group: >-
       ${{ github.event_name == 'pull_request_target' &&
       format('qwen-pr-review-pr-{0}', github.event.pull_request.number) ||
       format('qwen-pr-review-run-{0}', github.run_id) }}
     cancel-in-progress: "${{ github.event_name == 'pull_request_target' && (github.event.action == 'synchronize' || github.event.action == 'closed') }}"

   Every synchronize kills the in-flight review regardless of who pushed — the expression never consults github.event.sender.login.

   Why the 10-minute delay doesn't help here

   delay-automatic-review does debounce opened/synchronize via the qwen-pr-review-delay environment wait timer (currently 10 minutes per the comment in the file), but that only coalesces pushes less than 10 minutes apart. Autofix rounds in the #8830 timeline are ~40–90 minutes apart, so every push sails through the delay gate and cancels a review that needs 1–3 hours to finish a pass.

   The autofix side never waits for the review either

   qwen-autofix.yml line 155 explicitly excludes review-pr from the checks it waits on before pushing:

   NON_BLOCKING_CHECKS: '["review-pr"]'

   So the two workflows have no mutual synchronization at all: autofix pushes as soon as it has actionable (even partial) findings, and each push resets the review. With the */10 cron plus the pull_request_review: submitted trigger, partial findings are picked up within minutes — that's the "goto 2" in the loop description.

   Notes on the suggested fixes

   • Option 1 is directly implementable: cancel-in-progress accepts an expression, and github.event.sender.login is available on synchronize (sender = the pusher), so bot pushes can be excluded. Two caveats: (a) with cancellation disabled for bot pushes, each synchronize still enqueues a fresh run in the PR-scoped group and those runs then execute sequentially — to avoid a queue pile-up you'd likely want to skip the trigger itself for bot pushes (an option-3 variant), not just the cancellation; (b) the bot login is vars.AUTOFIX_BOT_LOGIN || 'qwen-code-dev-bot' in qwen-autofix.yml, so the guard should key off the same variable rather than a hardcoded login.
   • For options 1/3: a review that survives a bot push reviews the head it started on, so its findings lag the branch by one push. Probably acceptable for bot PRs (the next pass catches up), but it means the "review of record" trails the branch while autofix is active.
   • Option 2 is cheap on the autofix side: before pushing in the review phase, check gh run list --workflow qwen-code-pr-review.yml --branch <head> --status in_progress and defer the round if a review is running — the */10 cron retries naturally, so a deferral costs at most one tick. This also attacks the "partial findings → scope explosion" symptom directly, because autofix would respond to a complete pass.

   Net: option 3 for bot-authored PRs (review on opened/reopened and explicit /review; let the scheduled scan pick up the rest) combined with option 2 as the autofix-side guard looks like the smallest change that breaks the loop from both directions.
3. yiliang114

   closed this as completedin #8899on Aug 14, 2026
4. pull

   added a commit that references this issue on Aug 14, 2026

   fix(autofix): hold autofix rounds while review-pr is in flight (QwenL…

   ...

   6e21f72
5. wenshao

   added a commit that references this issue on Aug 26, 2026

   fix(ci): salvage superseded review runs and hold the loop's report-ti…

   ...

   4a4afb9
6. pull

   added a commit that references this issue on Sep 6, 2026

   fix(ci): salvage superseded review runs and hold the loop's report-ti…

   ...

   827c8aa