Repository navigation
[Bug]: a new watch_pull_request reports checks that had already passed as news #22184
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
- Open a GitHub PR whose required checks have all passed on the current head.
- In a thread, call
watch_pull_requeston it, and end the turn.
Seen on 2026-10-20 (UTC): the watch started at 05:52:53 on head 0410491, and CI on that head had passed hours earlier. At 05:53:25 the thread was woken with "checks passed". Nothing had changed: same head, same check runs. The agent spent a turn confirming it was "just CI going green again on the same commit".
Expected behavior
When a watch starts, the PR's current head, checks and reviews are its baseline. The thread wakes only for changes after that point.
Actual behavior
The first poll after the watch starts reports the existing state, "checks passed" here, as if it were new. Each new watch costs a turn on a possibly large thread (see #16829). It also teaches the agent to dismiss the first wake, which can be a real one.
Impact
Minor bug or occasional failure
Version or commit
T3 Code (Alpha) 0.0.68
Environment
macOS 27.0 (Apple Silicon), T3 Code desktop (Alpha), Claude Code provider, GitHub PR on github.com
Activity
Kameleon21 commentedon Oct 21, 2026
I'd like to work on this one.
I think I found the cause. When a PR is watched for the first time,
Orchestrator.tscreates the watch withheadSha: null, passed: false, passedChecks: []. The only time it seeds real state is from a previous watch'sendedWatch. On the first poll,evaluatePullRequestWatchinpullRequestWatch.tsthen seesheadSha !== watch.headShaand!passed, so it reportschecks-passedfor checks that had already passed. Comments are already handled correctly, becauseremarksThrough: startedAtserves as their baseline.Plan: treat the first evaluation of a fresh watch (one that has no recorded head yet) as the baseline. It records the head, the check results and whether the PR is conflicting, and wakes no one. Only later changes wake the thread. I'll add a test in the
pullRequestWatchtests: start a watch on a PR whose checks already passed, then check that the first poll produces no wake and that a later push or failure still does.One question first: should checks that are already failing when the watch starts still wake the thread once? You could argue the agent wants to know about those. Or should the baseline cover failures too, as this issue proposes?
emanuel-mrkr commentedon Nov 12, 2026
@Kameleon21 +1 to #23522, which baselines failing checks too. That's what we'd want.
An example from the second case in #22183: a watch started at 07:40:34 UTC. One check had failed on that head at 07:33:24, and the agent had already read it with
gh pr checksat 07:35:48 and reported it. At 07:41:07 the thread was still woken with "Checks failed on ", which cost a turn on information it already had. An agent that callswatch_pull_requesthas usually just looked at the PR.