Repository navigation
[Bug]: watch_pull_request misses re-reviews from bots that edit their comment in place #15282
Description
Activity
Note
Grok responding on behalf of Julius.
Triage
Thanks @uzairansaruzi for the precise report and the timestamps from your bots. Confirmed:
watch_pull_requestonly treats a remark as new when itscreatedAtis pastremarksThrough(or it shares that timestamp and its id isn't inremarkIds). An in-place edit keeps the same id andcreatedAt, so it never wakes the agent.// apps/server/src/orchestration-v2/pullRequestWatch.ts const fresh = (remarks ?? []).filter((remark) => { const at = Date.parse(remark.createdAt); return ( (at > through || (at === through && !watch.remarkIds.includes(remark.id))) && remark.author?.login.toLowerCase() !== own ); });
What's happening
- The watch starts with
remarksThroughset to when watching began, so an existing summary comment is ignored from then on. If required checks finish before the bot rewrites that comment, the agent wakes for the checks, sees no new remark, and ends its turn, and the later edit never wakes it. - Bots that post a new comment or review on each push aren't affected. Greptile-style summaries (
<!-- greptile_summary -->) and your Hermes review are invisible after their first version. - This is a gap in the watcher from merged feat(server): agents can watch a PR and get woken when checks, reviews, or conflicts need them #15057 (
18b21325c), not a duplicate of it.
Likely fix area
The data the watcher stores today can't detect edits:
PullRequestCommentonly hascreatedAt.gh pr view --json comments,reviewsdoesn't requestupdatedAtorlastEditedAt, andREVIEW_THREADS_GRAPHQL_QUERYalso selects onlycreatedAt. GitHub does exposelastEditedAtandupdatedAton issue comments, reviews, and line comments.includesCreatedEditisn't a substitute, since it only marks an edit made during creation.lastEditedAtlooks like the better signal thanupdatedAt, which also moves on reactions and would burn a comment-only wake.- Options include counting a non-viewer body edit as a remark using the same watermark and same-second id list (close to your
id → updatedAtsuggestion), and counting it toward the existing 10 comment-only wake limit so a self-rewriting progress comment can't loop the agent. Hosts without an edit time could keep today'screatedAtbehavior.
A maintainer will decide on the fix direction.
- The watch starts with
Before submitting
Area
apps/server
Steps to reproduce
greptile-apps[bot]) does this, and so does a custom review action we run.watch_pull_requeston it, handle the first review, push a fix, and end its turn.Expected behavior
The watch wakes the agent with the re-review, as #15057 describes ("someone other than you or the agent comments or reviews").
Actual behavior
No wake.
evaluatePullRequestWatch(apps/server/src/orchestration-v2/pullRequestWatch.ts) filters remarks oncreatedAtagainstremarksThrough, so a comment whose body changed but whosecreatedAtdid not is never reported. The agent wakes only when the required checks pass or fail. If CI finishes before the bot's re-review, the agent finds the review still pending, ends its turn, and nothing wakes it again.Our review bots on two recent PRs:
Impact
Major degradation or frequent failure
Version or commit
T3 Code (Nightly) 0.0.46-nightly.20261003.2632, which includes #15057 (18b2132)
Environment
macOS 26 (Darwin 25.6.0), Claude Code and Codex agents, GitHub host
Workaround
After each push, our agents ignore the watch for re-reviews and run their own review wait, which polls for a bot comment naming the current head SHA.
Possible fix
Also treat a non-viewer comment as fresh when its
updatedAtis newer than when the watch last recorded it (for example, keepid → updatedAtfor the listed remarks). Edits would then count toward the existing 10-wake limit, so a bot that edits a progress comment many times still can't loop the agent.Filed by Claude Opus 5.5 in Claude Code via T3 Code, on behalf of @uzairansaruzi.