re-review workflow reports "Complete" but durable verdict marker not refreshed to new head SHA

[solomonneas]

ClawSweeper's @clawsweeper re-review workflow posts a progress block that says State: Complete and "the durable review comment was updated, and the synced verdict was routed", but the durable review comment's verdict marker stays pinned to the SHA from the original review and never refreshes against the current PR head.

Repro

Both observed on openclaw/openclaw#72295.

Run 1

• Re-review requested: 2026-05-12 16:40 UTC (Agents: broaden strict-agentic actionable-prompt and active-narration gates openclaw#72295 (comment))
• Workflow run: https://github.com/openclaw/clawsweeper/actions/runs/25748589643
• Progress block: State Complete, Updated 2026-05-12T16:48:19.455Z
• PR head at request: 1c826a861ac48a904cdaedd2339a11b798493022
• Durable review marker SHA after run: d2171647e1f54ae9f700b26438f757fd5dd3c916 (unchanged from original 2026-04-28 review)

Run 2 (independent repro 10 days later)

• Re-review requested: 2026-05-22 12:37 UTC (Agents: broaden strict-agentic actionable-prompt and active-narration gates openclaw#72295 (comment))
• Workflow run: https://github.com/openclaw/clawsweeper/actions/runs/26288252854
• Progress block: State Complete, Updated 2026-05-22T12:45:43.266Z
• PR head at request: 1c826a861ac48a904cdaedd2339a11b798493022
• Durable review marker SHA after run: d2171647e1f54ae9f700b26438f757fd5dd3c916 (still unchanged)

Impact

Labels stay stuck where the original review left them (in this case status: ⏳ waiting on author), even when the author has pushed fixes addressing the original findings. Maintainers filter by these labels, so a stuck waiting on author effectively buries the PR. The author has no signal that the re-review didn't actually happen, since the progress block says it did.

Likely cause

The progress-block update path and the durable-comment edit path appear to be decoupled. The status comment is being updated optimistically before the verdict edit succeeds, or the verdict edit silently no-ops when the new review run produces an identical verdict body, leaving the SHA marker stale.

Suggested signal

Even if the re-review intentionally produces the same verdict text, the SHA marker in the durable comment should be bumped to the re-reviewed head SHA so authors and maintainers can tell the rerun actually happened.

[clawsweeper]

Thanks for the report. I gave this a fresh shell check against current main, and I could not reproduce it anymore.

The cited runs do not show a stale durable verdict marker: each run reviewed the same head SHA recorded by its command marker and routing output, while the issue compares the second run against an older head that was no longer current.

Review details

Best possible solution:

Keep the current behavior, and open a new focused issue only if a run log and an immediately captured durable comment demonstrate that the marker differs from the exact head_sha reviewed in that same run.

Do we have a high-confidence way to reproduce the issue?

No. The cited logs show that run 25748589643 reviewed head 1c826a…3022, while run 26288252854 reviewed head d21716…c916; each run's command and routing data agree with its own reviewed head.

Is this the best way to solve the issue?

No, not from the cited evidence. Adding a second live comment-discovery path would add API and trusted-bot compatibility complexity without fixing a demonstrated stale-marker event.

Security review:

Security review: This issue does not include a patch requiring a security or supply-chain review.

AGENTS.md: found and applied where relevant.

What I checked:

• First run reviewed the requested head: Run 25748589643 carried command status SHA 1c826a861ac48a904cdaedd2339a11b798493022, and its routed verdict output used that same expected and target head SHA before reporting Complete.
• Second run reviewed the later head: Run 26288252854 carried command status SHA d2171647e1f54ae9f700b26438f757fd5dd3c916 and its target output recorded the same head SHA, so the durable marker cited by the issue was fresh for that re-review rather than pinned to the earlier head.
• Pull-request head provenance: The target pull request's current head and final listed commit are d2171647e1f54ae9f700b26438f757fd5dd3c916, matching the second re-review marker and run output. (d2171647e1f5)
• Targeted repair was withdrawn after log review: The proposed marker-freshness pull request was closed unmerged after its author checked live logs and concluded the reported incident did not reproduce; its review also identified compatibility complexity in the proposed independent comment lookup. (2eab61ea1b44)
• Current gate history: The event publish path and outcome-based completion block appear together in commit e48915a, which is the central history point for future hardening if a swallowed-edit failure is independently reproduced. (.github/workflows/sweep.yml:481, e48915a6b06c)

Likely related people:

• Peter Steinberger: Git blame attributes the event result publisher and re-review completion gate to commit e48915a. (role: introduced behavior; confidence: high; commits: e48915a6b06c; files: .github/workflows/sweep.yml, src/repair/publish-event-result.ts)
• brokemac79: Recent merged work changed issue-author re-review parsing and duplicate command acknowledgement behavior in the adjacent command-router core. (role: recent area contributor; confidence: medium; commits: 485f71abc664, 556268dff3d9; files: src/repair/comment-router-core.ts)
• Tak Hoffman: Recent merged changes touched repair finding routing and duplicate command handling near the event re-review workflow. (role: recent repair-lane contributor; confidence: medium; commits: 8db024ba0503, c01469876a85; files: src/repair/comment-router-core.ts, .github/workflows/sweep.yml)

Codex review notes: reasoning high; reviewed against 9209fa90cb3c.

[Takhoffman]

@clawsweeper visualize

[clawsweeper]

🦞👀
ClawSweeper visual brief is being prepared.

I queued a read-only visual pass. It will create or update one marker-backed visual brief comment and will not trigger close, merge, repair, label, or branch changes.

Lens: auto

[clawsweeper]

Source: #170 (comment)
Visual model: gpt-5.5, reasoning low.

Visual brief

Lens: state

Advisory only. Maintainers remain the final judges.

Issue: https://github.com/openclaw/clawsweeper/issues/170
Subject: re-review says Complete, but durable verdict marker stays on old SHA

Expected re-review state flow

@clawsweeper re-review
        |
        v
current PR head captured
1c826a861ac48a904cdaedd2339a11b798493022
        |
        v
durable review comment updated
marker SHA = 1c826a861ac48a904cdaedd2339a11b798493022  ✅
        |
        v
labels/verdict routed from refreshed review state ✅
        |
        v
progress block may say Complete ✅

Observed state flow

@clawsweeper re-review
        |
        v
current PR head captured
1c826a861ac48a904cdaedd2339a11b798493022
        |
        v
progress block says Complete ✅
"durable review comment was updated"
        |
        v
durable review marker still old SHA ❌
d2171647e1f54ae9f700b26438f757fd5dd3c916
        |
        v
labels can remain tied to stale review state ⚠️
example: status waiting on author

Two repros, same mismatch

+------+------------------+------------------+------------------+------------------+
| Run  | Request time UTC | Progress result  | PR head requested | Marker after run |
+------+------------------+------------------+------------------+------------------+
| 1    | 2026-05-12 16:40 | Complete ✅       | 1c826a...3022     | d21716...c916 ❌ |
| 2    | 2026-05-22 12:37 | Complete ✅       | 1c826a...3022     | d21716...c916 ❌ |
+------+------------------+------------------+------------------+------------------+

Likely split-brain state

🧠 runtime/progress state
    "workflow complete"
    "comment updated"
           |
           | not proving
           v
💾 durable verdict marker
    still points to original 2026-04-28 review SHA

Legend: ✅ expected/proven working, ❌ broken path, ⚠️ unresolved risk, 🧠 runtime state, 💾 persisted state.

Maintainer judgment points:

🧑‍⚖️ Is "Complete" allowed before the durable verdict marker is proven refreshed?

🧑‍⚖️ If verdict text is identical, should the SHA marker still bump to the
     re-reviewed head SHA as proof the rerun actually happened?

🧑‍⚖️ Should label routing depend on confirmed durable marker freshness rather
     than only progress-step success?

Main operator-visible risk:

Author pushes fixes
        |
        v
re-review appears successful ✅
        |
        v
durable marker remains stale ❌
        |
        v
status label can stay "waiting on author" ⚠️
        |
        v
maintainer queues may bury the PR ⚠️

Maintainer ruling

Benefit:
Risk:
Proof needed:
Recommended next action:
Question presented: