qodo-gate: accept Qodo's update-in-place re-review as current-head evidence

[josephnef]

Follow-up gap found while landing #356: a /review summon after a push does not submit a new review object — Qodo edits its code-review comment in place and posts a marker comment naming the head sha ("updated up to the latest commit <oid>"). The gate's strict review-object/head-oid match therefore blocks forever on the summon path (observed live on #356; #357's summons happened to produce review objects).

The gate now accepts either evidence form:

1. a review object tied to the current head oid (unchanged), or
2. a bot-authored comment matching "up to the latest commit" and containing the exact head oid (verified against Kestrel per-antenna stats: CRC-gate window aggregates + pure physts output param (#355 review) #356's live data).

Only the bot's own comments count, so this is not spoofable by other users. Comment edits can't retrigger the check against the PR head (issue_comment runs attach to the default branch), so the retrigger paths stay: thread reply or Checks-tab re-run — documented in the failure message.

🤖 Generated with Claude Code

[qodo-free-for-open-source-projects]

PR Summary by Qodo

qodo-gate: accept Qodo “updated up to latest commit” marker as head evidence

🐞 Bug fix ⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Unblock qodo-gate when /review re-reviews update comments in place (no new review object).
• Accept bot-authored “up to the latest commit ” marker comments as head-sha evidence.
• Clarify rerun/retrigger instructions when the gate fails after a summoned re-review.

Diagram

graph TD
  A["qodo-gate workflow"] --> B{{"Head-tied Qodo review exists?"}} -->|"yes"| F["Pass gate"]
  B -->|"no"| C["List PR issue comments"] --> D{{"Bot marker names head SHA?"}} -->|"yes"| F
  D -->|"no"| E["Fail with rerun guidance"]

  subgraph Legend
    direction LR
    _p["Process"] ~~~ _d{"Decision"}
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Use GraphQL timelineItems instead of REST issue comments

• ➕ Single API surface (GraphQL) and easier to co-locate with existing PR query
• ➕ Can query and filter comment authors/bodies without pagination shell loops
• ➖ Timeline APIs can be trickier to shape correctly and may require additional scopes/fields
• ➖ Still relies on string-matching Qodo’s marker text, just via a different endpoint

2. Key off check runs/statuses produced by Qodo (if available)

• ➕ More structured/less fragile than parsing human-readable marker text
• ➕ Naturally tied to commit SHA and integrates with Checks UI
• ➖ Only works if Qodo emits per-SHA check runs; may not exist for this integration
• ➖ Would require a more substantial gate redesign and migration path

Recommendation: The PR’s approach is a pragmatic, low-risk fix: keep the strict head-SHA review-object check, and add a narrowly-scoped fallback that only trusts Qodo bot-authored marker comments containing the exact head SHA. Consider a future shift to structured evidence (check runs) if Qodo exposes it; otherwise GraphQL timelineItems could simplify the comment scan but is not strictly necessary.

Files changed (1) +21 / -3

Bug fix (1) +21 / -3

qodo-gate.ymlAdd fallback head-SHA validation via Qodo marker comments +21/-3

Add fallback head-SHA validation via Qodo marker comments

• Extends the gate to accept a second form of “current head” evidence when Qodo re-reviews by editing its comment in place and posting an “updated up to the latest commit <sha>” marker. If no head-tied review object exists, the workflow paginates issue comments and counts bot-authored marker comments that include the exact head OID, and improves the failure message with correct rerun instructions.

.github/workflows/qodo-gate.yml

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Missing issues read permission ✓ Resolved 🐞 Bug ☼ Reliability

Description

The new fallback queries repos/.../issues/$PR/comments but the workflow only grants `contents:
read and pull-requests: read`, so the REST call can 403 and block the gate even when the bot
marker comment exists. This makes the new evidence path unreliable or unusable under the workflow’s
explicitly restricted GITHUB_TOKEN permissions.

Code

.github/workflows/qodo-gate.yml[R95-96]

+            current=$(gh api "repos/$REPO_OWNER/$REPO_NAME/issues/$PR/comments" \
+              --paginate --jq "[.[]

Evidence

The workflow explicitly restricts GITHUB_TOKEN permissions to contents: read and `pull-requests:
read, but the new fallback uses the Issues comments REST endpoint, which is governed by issues`
permissions; without issues: read the call can be rejected and the fallback cannot evaluate
comments.

.github/workflows/qodo-gate.yml[28-31]
.github/workflows/qodo-gate.yml[94-100]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The workflow calls the Issues comments REST endpoint (`repos/{owner}/{repo}/issues/{number}/comments`) but the job token permissions do not include `issues: read`, which can cause the `gh api` call to fail (403) and the gate to fail even when Qodo posted the expected marker comment.
### Issue Context
This fallback is executed when no current-head review object exists. The workflow has an explicit `permissions:` block, so missing scopes are not implicitly available.
### Fix Focus Areas
- .github/workflows/qodo-gate.yml[28-31]
- .github/workflows/qodo-gate.yml[94-100]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Paginated count not aggregated ✓ Resolved 🐞 Bug ≡ Correctness

Description

The fallback uses gh api --paginate --jq '[...] | length' and then treats the result as a single
integer in [ "$current" -eq 0 ]. If the endpoint returns multiple pages, the command substitution
can yield multiple counts (one per page), which can break the numeric test or mis-evaluate and miss
a valid marker on later pages.

Code

.github/workflows/qodo-gate.yml[R96-99]

+              --paginate --jq "[.[]
+                | select(.user.login == \"${BOT}[bot]\")
+                | select(.body | test(\"up to the latest commit\"))
+                | select(.body | contains(\"$head_oid\"))] | length")

Evidence

The added fallback explicitly enables pagination and computes a length, then immediately performs
a numeric -eq comparison that requires current to be a single integer value; the script does not
aggregate across pages before that numeric test.

.github/workflows/qodo-gate.yml[94-101]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The script assumes `current` is a single integer, but it combines `--paginate` with a `--jq` expression that computes `length` per response. With multiple pages, this can produce multi-line output that is not a valid integer for `-eq`, and can also fail to correctly account for matches on later pages.
### Issue Context
This code runs in the fallback path when no current-head review object exists. PRs with >100 issue comments can trigger multiple pages.
### Fix Focus Areas
- .github/workflows/qodo-gate.yml[94-101]
### Suggested implementation direction (example)
Replace `--paginate --jq ...` with an explicit aggregation, e.g.:
- `gh api ... --paginate | jq -s --arg ... '[.[][] | ...] | length'`
so the output is always one scalar integer.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

[josephnef]

/review

[qodo-free-for-open-source-projects]

Code review by qodo was updated up to the latest commit 52ee466