Re-review acknowledgement assumes a durable review comment already exists

[anagnorisis2peripeteia]

I ran into this while using GitHub: On PR #576, @clawsweeper re-review was accepted into the exact-review queue before any durable ClawSweeper review comment existed, but the command-status reply promised that the existing review comment would be edited in place. Both enqueue-only workflows completed successfully; this report is about the inaccurate acknowledgement, not review-queue latency.

I expected the acknowledgement to remain accurate for both supported paths: create the first durable review placeholder when none exists, or update the existing durable review comment.
Instead, the successful re-review response always says that the existing ClawSweeper review comment will be edited in place, including when no durable review marker exists yet.

I traced this to the dispatched re_review branch of renderResponse emitting a fixed existing-comment sentence. Its inputs do not carry review-comment existence, while the documented review lifecycle supports both creating a marker-backed placeholder and editing an existing durable comment; the focused test currently asserts the fixed sentence.
I verified that with the live PR having two accepted @clawsweeper re-review commands, one surviving command-status acknowledgement, no durable clawsweeper-review marker, and no posted review. Both repository-dispatch workflow runs completed successfully in enqueue-only mode. Current origin/main unconditionally emits and tests the existing-comment sentence, while docs/pr-review-comments.md says a review shard creates a marker-backed placeholder when no durable comment exists.

The raw artifacts I used are: #576 (comment) ; https://github.com/openclaw/clawsweeper/actions/runs/29362584394 ; https://github.com/openclaw/clawsweeper/actions/runs/29367358183 ;

clawsweeper/src/repair/comment-router-core.ts

Lines 2155 to 2169 in eda9768

	if (command.intent === "re_review") {
	return [
	marker,
	dispatched?.clawsweeper
	? "ClawSweeper re-review requested."
	: "ClawSweeper could not start a re-review for this item.",
	"",
	dispatched?.clawsweeper
	? [
	"I asked ClawSweeper to review this item again.",
	reviewDispatchLine(dispatched.clawsweeper, "Action", "item re-review queued"),
	"Result: the existing ClawSweeper review comment will be edited in place when the review finishes.",
	].join("\n")
	: `Reason: ${command.reason ?? "re-review requires an open issue or PR"}.`,
	].join("\n");

;

clawsweeper/test/repair/comment-router-core.test.ts

Lines 3150 to 3172 in eda9768

	test("renderResponse reports maintainer re-review dispatches", () => {
	const body = renderResponse(
	{
	comment_id: "461",
	intent: "re_review",
	issue_number: 74107,
	target: { head_sha: "def461" },
	},
	{
	clawsweeper: {
	workflow: "sweep.yml",
	event: "repository_dispatch",
	},
	},
	);
	assert.match(body, /re-review requested/);
	assert.match(body, /review this item again/);
	assert.match(body, /Action: item re-review queued/);
	assert.match(body, /existing ClawSweeper review comment will be edited in place/);
	assert.match(body, /clawsweeper-command-status:74107:re_review:def461/);
	assert.doesNotMatch(body, /repair worker/);
	});

;

clawsweeper/docs/pr-review-comments.md

Lines 21 to 33 in eda9768

	Each synced comment includes the durable identity marker:
	```html
	<!-- clawsweeper-review item=<number> -->
	```
	ClawSweeper edits that comment in place instead of posting repeated comments.
	Report front matter stores the synced comment id, URL, hash, and sync time.
	When review starts and no ClawSweeper-owned comment exists yet, the review
	shard posts a short status placeholder with the same durable identity marker.
	The placeholder is intentionally light and crustacean-friendly, then the final
	review sync edits that exact comment in place.

Reproduction: Open a pull request with no comment containing <!-- clawsweeper-review item=<number> -->, post @clawsweeper re-review, then inspect the bot command-status reply. On PR #576, comment 4973212500 says the existing review comment will be edited even though the issue-comment API has no durable review marker. The enqueue-only runs 29362584394 and 29367358183 both succeeded, so the command was accepted rather than rejected.
Environment: openclaw/clawsweeper origin/main at eda9768; GitHub command router; observed July 14, 2026 on PR #576 at head a3faecc.

Raw observation:

• Command: On openclaw/clawsweeper PR 576, post @clawsweeper re-review before any durable ClawSweeper review comment exists
• Status code: 1
• Output:

  Reproduced against public PR 576 and verified against origin/main 840022e7eff282c0904dc85be452ba261cd43a9b.
  

• I observed it 1 time(s).

[anagnorisis2peripeteia]

Additional live reproduction on #587:

• @clawsweeper re-review was triggered before any durable review comment existed.
• The router accepted the request and edited the command acknowledgement to say that “the existing ClawSweeper review comment will be edited in place.”
• The router dispatch run completed successfully, so this is independent of whether the queued review later posts; the acknowledgement is already asserting nonexistent state.

Evidence: #587 (comment)
Dispatch: https://github.com/openclaw/clawsweeper/actions/runs/29376113795

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 19, 2026, 12:00 AM ET / 04:00 UTC.

Summary
Keep this issue open: it describes a narrow acknowledgement defect, and the clean, proof-positive linked implementation PR #587 remains open as the explicit fix path. A human response confirmed it is separate from the publication incident and asked for no further changes until the next maintenance-pass review, so opening a second repair would duplicate active work.

Likely related people: brokemac79 is the best follow-up routing candidate from the recorded maintenance decision and adjacent review-publication work; anagnorisis2peripeteia is connected as the reporter and author of the linked narrow fix.

Reproducibility: yes. at source level: the report traces the unconditional acknowledgement text and contrasts it with the documented placeholder/create-or-update lifecycle. A fresh live current-main run was not established in the available evidence, so confidence is medium rather than high.

Root-cause cluster
Relationship: canonical
Canonical: #581
Summary: This issue is the canonical report for the acknowledgement wording defect; the open linked PR is the concrete candidate fix rather than a duplicate issue.

Members:

• fixed_by_candidate: fix(router): describe re-review comment upsert #587 - Its body explicitly targets the reported create-or-update acknowledgement wording, references this issue as the closing target, and includes focused regression coverage and before/after renderer proof.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Next step
The open, clean linked PR already owns the narrow implementation path, and the recorded human response explicitly requests no further changes before its maintenance-pass review.

Review details

Best possible solution:

Review and, if it still applies cleanly to current main, land #587 with its focused create-or-update acknowledgement regression coverage; do not start a parallel fix.

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

Yes, at source level: the report traces the unconditional acknowledgement text and contrasts it with the documented placeholder/create-or-update lifecycle. A fresh live current-main run was not established in the available evidence, so confidence is medium rather than high.

Is this the best way to solve the issue?

Yes: the linked PR changes only the inaccurate acknowledgement wording and adds focused assertions for both missing-comment creation and existing-comment update behavior, without changing dispatch or publication logic.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against c11d264870d2.

Label changes

Label changes:

• add issue-rating: 🐚 platinum hermit: Current issue advisory state selects this label.
• add clawsweeper:needs-live-repro: Current issue advisory state selects this label.
• remove issue-rating: 🦞 diamond lobster: Current issue advisory state no longer selects this label.
• remove clawsweeper:source-repro: Current issue advisory state no longer selects this label.

Label justifications:

• P3: The defect is limited to inaccurate command acknowledgement text and does not alter review dispatch or durable-comment publication behavior.
• impact:ux-friction: The acknowledgement can mislead contributors about whether a durable review comment already exists, creating avoidable support and review confusion.

Evidence reviewed

What I checked:

• Source-level defect report: The report identifies the fixed re-review acknowledgement branch in renderResponse, whose previous wording promised an existing durable review comment would be edited even when no marker-backed comment existed; the same report identifies the documented create-or-update lifecycle. (src/repair/comment-router-core.ts:2155, eda9768bd1b7)
• Linked implementation remains open: fix(router): describe re-review comment upsert #587 explicitly closes this issue, changes only the acknowledgement copy plus focused regression assertions, is cleanly mergeable, and reports real before/after renderer output. (src/repair/comment-router-core.ts:2166, d4ef85a37738)
• Human maintenance direction: The July 16, 2026 response confirms this is separate from the review-publication stability incident, says the acknowledgement wording and linked narrow fix will be reviewed in the next maintenance pass, and asks for no further changes meanwhile.
• Durable-comment contract: The public review-comment documentation describes one marker-backed durable review comment and a placeholder-first lifecycle when a completed comment does not yet exist, supporting the reported expected behavior. (docs/pr-review-comments.md:21, eda9768bd1b7)

Likely related people:

• brokemac79: Provided the recorded human maintenance-pass direction for this issue and authored the adjacent exact-review publication recovery, while distinguishing that incident from this acknowledgement defect. (role: recent area contributor; confidence: medium; commits: cf917b60a224; files: src/repair/comment-router-core.ts, docs/pr-review-comments.md)
• anagnorisis2peripeteia: Reported the reproducible acknowledgement mismatch and authored the focused open implementation candidate that covers both create and update wording. (role: linked fix author and reporter; confidence: high; commits: d4ef85a37738; files: src/repair/comment-router-core.ts, test/repair/comment-router-core.test.ts)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[brokemac79]

Thanks for the report. We?ve confirmed this is separate from the recent ClawSweeper review/publication stability incident.

The acknowledgement wording and its linked narrow fix will be reviewed in the next maintenance pass, after we have finished stabilising the recovered service. We will leave a specific decision here once that review is complete.

Please do not treat this as a request for further changes at present.