Re-post review findings when prior REQUEST_CHANGES was dismissed

[fullsend-ai-retro]

What happened

On PR #2853, the review agent posted a REQUEST_CHANGES review at 16:17 UTC with 3 medium findings including [submodule-trust] — a legitimate security concern about submodules: true cloning a third-party repo in CI. The author pushed 3 follow-up commits (16:55–17:18), which caused the REQUEST_CHANGES to be dismissed. The final review run (run 28535929661) completed successfully at 17:46 UTC but posted only a status comment ('Finished Review · Success') with no review body or findings. When rh-hemartin approved on Jul 2, the only agent review visible was the dismissed one — effectively invisible in GitHub's review UI. The [submodule-trust] finding was never addressed.

What could go better

The final review run appears to have suppressed its findings, likely because they matched the previous run's findings (deduplication logic). However, since the previous review was DISMISSED, those findings were no longer visible to human reviewers. This created a gap: the review agent correctly identified a security concern, ran successfully on the final commit, but produced no visible output for the human to act on. Confidence: medium-high — I cannot confirm the suppression reason without reading the agent's JSONL trace, but the observable behavior (successful review with no posted body after a dismissed prior review) is clear from the PR timeline. Existing issues #2816 (persistent finding cache) and #2677 (surface unresolved count in status comment) are related but neither addresses this specific interaction: re-review should detect that its prior formal review was DISMISSED and re-post persistent findings rather than treating them as already-visible.

Proposed change

In the review agent's post-processing logic (the post-script or review skill that decides whether to post findings), add a check: before suppressing findings as duplicates of a prior run, verify the prior review's GitHub review state. If the prior review was DISMISSED or if no active (non-dismissed) review from the bot exists on the PR, post findings even if they match a previous run. This ensures findings remain visible when GitHub's review dismissal mechanism removes the original review. The check could use gh api repos/{owner}/{repo}/pulls/{pr}/reviews filtered to the bot user, looking for any review in CHANGES_REQUESTED state that is not DISMISSED. If none exist and the current run has findings, post them.

Validation criteria

On the next 5 PRs where: (a) the review agent posts REQUEST_CHANGES, (b) the author pushes new commits causing the review to be dismissed, and (c) the re-review finds persistent findings — the re-review should post a new review body with findings rather than only a status comment. Verify by checking that no PR reaches human approval with zero visible (non-dismissed) agent reviews when the agent has active findings.

---

Generated by retro agent from #2853

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 12:23 PM UTC · Completed 12:28 PM UTC
Commit: 9f4f2b6 · View workflow run →

[fullsend-ai-triage]

Triage Summary

This is a high-severity bug in the review agent's finding deduplication logic.

Problem

When the review agent posts a REQUEST_CHANGES review and the PR author pushes follow-up commits, GitHub automatically dismisses the prior review. The subsequent re-review run correctly identifies the same findings but suppresses them as duplicates of the prior run — without checking that the prior formal review was dismissed and is no longer visible to human reviewers. This creates a gap where security findings (like [submodule-trust]) are silently dropped from visibility.

Root Cause Hypothesis

The deduplication logic matches current findings against prior run findings and suppresses duplicates, but does not verify the GitHub review state of the prior run's formal review. When the prior review is DISMISSED, findings should be re-posted since they are no longer visible in GitHub's review UI.

Recommended Fix

In the review post-processing logic, before suppressing findings as duplicates:

1. Query the PR's reviews filtered to the bot user
2. Check if any non-dismissed CHANGES_REQUESTED review exists
3. If no active review exists and the current run has findings, post a new formal review regardless of dedup match

Key files to investigate: internal/cli/postreview.go (dismissal logic around dismissStaleRequestChanges), the review skill's finding synthesis, and internal/sticky/sticky.go (comment archival).

Related Issues

• Review agent: persistent finding cache for cross-iteration deduplication and dismissal enforcement #2816 — persistent finding cache (complementary, not blocking)
• Review status comment should surface unresolved finding count for human reviewers #2677 — surface unresolved count in status comment (complementary, not blocking)

Proposed Test Case

Scenario: Re-review re-posts findings when prior REQUEST_CHANGES is dismissed
  Given a PR with a prior bot review in DISMISSED state containing [submodule-trust]
  And the current re-review run produces the same [submodule-trust] finding
  When the post-review logic runs deduplication
  Then a new REQUEST_CHANGES review is posted with [submodule-trust]

Edge cases:
  - Prior review exists but is NOT dismissed → dedup suppresses as before
  - Multiple prior reviews, some dismissed, some active → do not re-post if any active review contains the findings
  - Prior review dismissed but findings resolved in new commits → do not re-post resolved findings

---

Labels: Review agent defect involving security findings being silently suppressed; high priority due to impact on review visibility.

[fullsend-ai-coder]

🤖 Finished Code · ❌ Failure · Started 12:29 PM UTC · Completed 12:44 PM UTC
Commit: 9f4f2b6 · View workflow run →