fix(ci): stop the fallback comment from denying a review it already posted

.github/workflows/qwen-code-pr-review.yml

@@ -1756,6 +1756,62 @@ jobs:
             echo "Fallback comment dedup lookup failed; deferring to the fallback-comment job." >> "$GITHUB_STEP_SUMMARY"
             exit 0
           fi
+          # Same guard as the fallback-comment job's, for the same reason: a
+          # review posted moments before this step runs makes every body
+          # below — each one ending in a retry instruction — contradict the
+          # review already on the PR. Scoped to the bot's own account and to a
+          # submission at or after this run was CREATED, so a stale review from
+          # an earlier run cannot silence a genuinely dead one; an unavailable
+          # creation time declines to fire and posts.
+          # What a match proves, exactly: a bot review of this PR was
+          # submitted while this run was alive. It is deliberately NOT keyed on
+          # the reviewed head. Two revisions of this guard were, and the head
+          # is not a stable attribute of a run: a push moves the PR's head
+          # between the post and this step, and a re-run recomputes the
+          # reviewed head from a later attempt — in both, THIS run's own review
+          # stops matching and the contradictory comment ships. The window is
+          # anchored on `createdAt`, not `startedAt`, against the same class of
+          # drift: re-running a failed job keeps the run id (the dedup above
+          # relies on that) while run-level `startedAt` moves to the
+          # re-executed attempt — measured on runs 32219268680 (created
+          # 05:23:57Z, startedAt 05:51:26Z) and 32218596441 (05:13:04Z →
+          # 05:22:05Z).
+          #
+          # Under this workflow's per-run concurrency an overlapping run's
+          # review can also fall inside the window, and then this run's failure
+          # goes unannounced. Accepted: that silence coincides with a bot
+          # review of this PR a reader can see, which is exactly the state that
+          # makes this comment's claim false. What the bot-author and
+          # creation-time clauses rule out is silence with NO review at all.
+          # The anchor is the run's CREATION, never its start. Re-running a
+          # failed job keeps the run id — the dedup above relies on exactly
+          # that — but moves run-level `startedAt` to the re-executed attempt:
+          # measured on this repo's runs 32219268680 (created 05:23:57Z,
+          # startedAt 05:51:26Z) and 32218596441 (05:13:04Z → 05:22:05Z).
+          # Anchoring there would push attempt 1's review outside "this run"
+          # on every re-run, so a re-run that fails before posting would
+          # contradict the review attempt 1 had posted — the very shape this
+          # guard exists to stop. `createdAt` is attempt-stable, and a review
+          # submitted after the run was created still cannot belong to an
+          # earlier run.
+          run_created="$(gh run view "${GITHUB_RUN_ID:?}" --repo "$GITHUB_REPOSITORY" --json createdAt --jq '.createdAt' 2>/dev/null)" || run_created=""
+          posted_reviews=""
+          # Three outcomes, and the guard must not be silent about the third:
+          # a lookup that DIED degrades to the false comment this whole change
+          # removes, and an oncall reading the log could not tell it from "no
+          # review matched". Every sibling lookup in this step announces its
+          # failures; this one says so too, then posts.
+          if [ -z "$run_created" ]; then
+            echo "::warning::already-posted guard unavailable (no run creation time); posting the fallback comment"
+            echo "Already-posted guard unavailable (run creation time missing); proceeding to post." >> "$GITHUB_STEP_SUMMARY"
+          elif ! posted_reviews="$(gh api "repos/${GITHUB_REPOSITORY}/pulls/${PR_NUMBER}/reviews" --paginate \
+            --jq ".[] | select(.user.login == \"$bot_login\") | select(.submitted_at >= \"$run_created\") | .id" 2>/dev/null)"; then
+            echo "::warning::already-posted guard unavailable (reviews listing failed); posting the fallback comment"
+            echo "Already-posted guard unavailable (reviews listing failed); proceeding to post." >> "$GITHUB_STEP_SUMMARY"
+          elif [ -n "$posted_reviews" ]; then
+            echo "Skipping fallback comment: a bot review of this PR was submitted after this run was created." >> "$GITHUB_STEP_SUMMARY"
+            exit 0
+          fi
           MAX_TIMEOUT_MINUTES="${{ vars.QWEN_REVIEW_MAX_TIMEOUT_MINUTES }}"
           if [ "$FAILURE_KIND" = "timeout" ]; then
             if [ "$TIMEOUT_MINUTES" -lt "$MAX_TIMEOUT_MINUTES" ]; then
@@ -1944,6 +2000,62 @@ jobs:
             echo "Skipping fallback comment: PR #${PR_NUMBER} is ${pr_state}." >> "$GITHUB_STEP_SUMMARY"
             exit 0
           fi
+          # A run that DID post its review must not be announced as one that
+          # could not. The review job can fail AFTER the post — the CLI exiting
+          # silently, a cleanup step dying — and this body's claim ("failed
+          # before a review could be posted"), with its retry instruction, then
+          # contradicts the review sitting right above it. Measured on PR
+          # #9342: the review posted at 11:56:34Z, the job failed at 12:00:53Z,
+          # and this comment landed at 12:01:00Z asking for a fresh ~3-hour
+          # review; the autofix takeover loop reads the same feed a human does.
+          #
+          # What a match proves, exactly: a bot review of this PR was
+          # submitted while this run was alive. It is deliberately NOT keyed on
+          # the reviewed head. Two revisions of this guard were, and the head
+          # is not a stable attribute of a run: a push moves the PR's head
+          # between the post and this step, and a re-run recomputes the
+          # reviewed head from a later attempt — in both, THIS run's own review
+          # stops matching and the contradictory comment ships. The window is
+          # anchored on `createdAt`, not `startedAt`, against the same class of
+          # drift: re-running a failed job keeps the run id (the dedup above
+          # relies on that) while run-level `startedAt` moves to the
+          # re-executed attempt — measured on runs 32219268680 (created
+          # 05:23:57Z, startedAt 05:51:26Z) and 32218596441 (05:13:04Z →
+          # 05:22:05Z).
+          #
+          # Under this workflow's per-run concurrency an overlapping run's
+          # review can also fall inside the window, and then this run's failure
+          # goes unannounced. Accepted: that silence coincides with a bot
+          # review of this PR a reader can see, which is exactly the state that
+          # makes this comment's claim false. What the bot-author and
+          # creation-time clauses rule out is silence with NO review at all.
+          run_created="$(gh run view "${GITHUB_RUN_ID:?}" --repo "$GITHUB_REPOSITORY" --json createdAt --jq '.createdAt' 2>/dev/null)" || run_created=""
+          posted_reviews=""
+          # Three outcomes, and the guard must not be silent about the third:
+          # a lookup that DIED degrades to the false comment this whole change
+          # removes, and an oncall reading the log could not tell it from "no
+          # review matched". Every sibling lookup in this step announces its
+          # failures; this one says so too, then posts.
+          # The head this run REVIEWED, not the PR's head at fallback time: on
+          # every trigger but pull_request_target the head-moved guard above
+          # deliberately does not run, so a push landing between the post and
+          # this step leaves `pr_head` pointing at bytes no review ever
+          # covered — the reviewed head's review then matches nothing and the
+          # contradictory comment posts anyway. Executed through this file's
+          # harness, that interleaving reproduces the #9342 shape exactly.
+          # The job output is empty only when review-pr died before its review
+          # step ran, which is also a run that posted nothing.
+          if [ -z "$run_created" ]; then
+            echo "::warning::already-posted guard unavailable (no run creation time); posting the fallback comment"
+            echo "Already-posted guard unavailable (run creation time missing); proceeding to post." >> "$GITHUB_STEP_SUMMARY"
+          elif ! posted_reviews="$(gh api "repos/${GITHUB_REPOSITORY}/pulls/${PR_NUMBER}/reviews" --paginate \
+            --jq ".[] | select(.user.login == \"$bot_login\") | select(.submitted_at >= \"$run_created\") | .id" 2>/dev/null)"; then
+            echo "::warning::already-posted guard unavailable (reviews listing failed); posting the fallback comment"
+            echo "Already-posted guard unavailable (reviews listing failed); proceeding to post." >> "$GITHUB_STEP_SUMMARY"
+          elif [ -n "$posted_reviews" ]; then
+            echo "Skipping fallback comment: a bot review of this PR was submitted after this run was created." >> "$GITHUB_STEP_SUMMARY"
+            exit 0
+          fi
           body="**Qwen Code review did not complete successfully.** The review pipeline failed before a review could be posted. A transient error is retried automatically; if you are seeing this, retry with \`@qwen-code /review\`. See [workflow logs](${RUN_URL})."
           body="$(printf '%s\n\n%s' "$FALLBACK_MARKER" "$body")"
           gh pr comment "$PR_NUMBER" \