fix(server): a PR watch wakes once for a comment's edits, not on every edit#30674

Approvability

Verdict: Approved at f6b63cd

Macroscope's review found this PR approvable — PR watches now wait for comment edits to stabilize before waking the agent, while new comments still arrive immediately. The change is limited to watch state and notification timing, with existing wake limits preserved.

^{You can add or adjust custom eligibility rules. Learn more.}

Explain Change →

No actionable comments were generated in the recent review.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

External image Recent review info

External image Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 6c9adfb
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: 7862d2ef-e151-4bee-b477-7a07dd13c682

External image Commits

Reviewing files that changed from the base of the PR and between 4c2f9c320fa606ef91519edcff26c9b0fd77da12 and 74cb82fac065603559d537baaaa9aa801ae1d4a0.

External image Files selected for processing: 6

• apps/server/src/orchestration-v2/Orchestrator.ts
• apps/server/src/orchestration-v2/PullRequestWatchReactor.ts
• apps/server/src/orchestration-v2/pullRequestWatch.test.ts
• apps/server/src/orchestration-v2/pullRequestWatch.ts
• apps/server/src/orchestration-v2/runtimeLayer.test.ts
• packages/contracts/src/threadPullRequest.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 7 remain after this review.

Verified in a real dev environment

Found and fixed a missing part of the GitCafe path in 00de53dacccd4583e7a4e3d9920640870dd0d879. The host returned comment updatedAt, but the adapter discarded it, so neither github/main (8b44f42b14) nor the original PR head (de32a70542) notified the agent about edits. The correction preserves that timestamp as editedAt for the PR's coalescing logic, for both top-level and review-thread comments.

Ran one real dev server at a time on Linux. Used Playwright from the repo with /usr/bin/google-chrome to create a project pointing at the real checkout and send Codex gpt-6.1-sol turns through the local proxy. Used this single real GitHub comment, mirrored into GitCafe, rather than mock host data.

The running server held successive versions on the 08:57, 08:59 and 09:01 UTC reads with wakes: 0 and no new provider turn. At 09:03:16, the unchanged version produced exactly one edited comments notification containing 1 edited comment, and Codex acknowledged it in the client. After the 09:05 sweep, the count remained one, pending edits were empty, and there was no duplicate provider turn. Also exercised new-comment delivery on main, checks-passed delivery on the PR, and the client's Stop action, which removed the watch and its background task.

Extended an existing adapter test and observed it fail before the correction, then pass. Blacksmith vp run check:changed passed formatting, lint, knip, GraphQL, typechecks of 36 affected packages, and 165 tests across five files. The fix was pushed without force to the contributor's existing PR branch and to origin branch maria/takeover-pr-30674. All 28 checks are now successful on this head. Two independent read-only reviewers also found no code issues at this exact SHA. This is runtime verification, not permission to merge.

Runtime command transcript

main: new comment delivered, subsequent edit omitted

corrected PR: one edited-comment notification acknowledged by real Codex

settled edit wakes Codex once in the real web client

Not verified

Direct GitHub watching: the available GitHub account is also the comment author and is excluded by that watch path. GitCafe uses its local viewer handle while retaining the mirrored GitHub author login, which allowed the real edit sequence above. The original repeated-wake symptom was not reproduced directly on GitHub; the reproduced failure was missing edit delivery on GitCafe.

Native desktop/mobile clients and other providers were not exercised. Live paginated review-thread tails, failed host reads and the ten-wake limit were not induced; the existing focused runtime/watch tests cover those cases. Uploaded video playback and seeking were checked in T3's rendered player.

@coderabbitai Both outside-diff findings from the 00de53dacc review were valid. They are fixed in 4c2f9c320f:

• Rewatch drops a held edit (Orchestrator.ts): the restart initializer now carries endedWatch.pendingEdits forward, as it already does for check state. I extended wakes once for a bot comment's edits after they settle under a quiet fingerprint to stop and restart the watch while an edit is held. It failed before the fix (no wake) and passes now (exactly one wake).
• Cached activity with a null fingerprint (PullRequestWatchReactor.ts): readGroup now invalidates when holdsEdits(group) is true. I didn't add a test because the reactor tests mock the read cache, and the race needs another reader to fill the cache inside its 60s window.

vp run check:changed passes.

@Umais-Adeed I inspected 4c2f9c320f. Both fixes address the reported findings.

• Rewatch: Orchestrator.ts carries endedWatch.pendingEdits into the restarted watch. The regression test stops and restarts while an edit is held, then asserts exactly one edited-comment wake and no duplicate on the next sweep.
• Null fingerprint: readGroup invalidates cached reads when holdsEdits(group) is true, even with a null fingerprint. It also clears cached thread tails before reading.

The cache-race scenario remains untested. A focused follow-up could use a cache-aware test double: prefill stale activity, return a null fingerprint, and verify that a held edit causes invalidation before the activity read.

I did not run tests here. Your reported vp run check:changed result provides the execution evidence.

📝 Learnings were not changed: only organization members or users with write access to this repository can add or remove learnings.

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

_{You are interacting with an AI system.}

Thanks for this. One case it still leaves open, in case it is useful before merge:

CodeRabbit, while a review is rate limited, rewrites its walkthrough every few minutes with a countdown ("Or wait 57 minutes for your next included review"). Each rewrite stays unchanged for longer than one sweep, so under this PR each one is held, found stable, and delivered. On one watched merge request that pattern produced 14 wakes in 86 minutes before the comment limit ended the watch, all for the same summary comment on the same head. CI status comments that a runner rewrites per job behave the same way.

A rule that composes with yours: report at most one edit per comment per head. The watch keeps the ids of comments whose edit it already reported on the current head and clears them on a push, so the first edit after a push still wakes (keeping #15282 fixed) and a comment that is new to the watch is unaffected. With both, a settling edit wakes once, and a bot that keeps rewriting on one head wakes once until the next push. The cost: a bot that edits findings into its summary twice on one head is reported for the first only; bots that post findings as new comments are unaffected.

We run that rule in a fork with tests (four reads of one head with the same comment edited each time: 4 wakes on main, 1 with the rule; nine edits over two heads: 9 against 2). Happy to open it as a follow-up on top of this PR if you want it, or to drop it if one wake per pause is the intended behaviour.

Thanks, good catch. I'd like to keep this PR focused on the settle-then-wake fix, so please open the one-wake-per-head rule as a follow-up on top of it. Happy to review it.

Evidence

Evidence: Run the real web app with fresh synthetic state and a replay thread. Watch an open synthetic PR, deliver one comment, edit it before three successive two-minute reads, then allow two unchanged sweeps. GitHub HTTP responses were supplied by a synthetic fixture; the server watch timer and processing were unchanged. Chromium, light theme, 1280×800 CSS pixels on both sides.

Reproduction drivers · Base runtime transcript · Head runtime transcript

AI-assisted; verified with the tests and tools listed above.

Not shown:

• Live GitHub account and network interaction: comment versions came from synthetic HTTP responses rather than external forge writes.
• GitCafe preservation of comment edit timestamps: this reproduction exercised the GitHub adapter.
• Pending-edit preservation across stopping and restarting a watch: both watches remained active throughout.