PR watcher misses successful replacement CI when job names change #30378

What happened

T3 Code 0.1.6 missed a successful CI wake for a watched pull request. A superseded CI run left two cancelled checks in GitHub's check rollup. The replacement run succeeded with different job names, so T3 retained the cancelled checks and never sent a checks-passed wake.

The PR snapshot showed checksState: "passing" while the watch retained passed: false. The thread resumed only after a manual user message.

Diagnosis

The saved reproduction uses check normalization and watch evaluation functions extracted from the installed 0.1.6 runtime, with captured GitHub contexts.

dedupeChecks identifies checks by workflow name and job name. Successful replacement jobs with different names do not replace cancelled jobs from the superseded run.

evaluatePullRequestWatch treats cancelled checks as failures. When no checks are marked required, all retained checks form the gate, so stale cancellations block success.

Replaying the captured contexts reproduces the failure. Excluding only the superseded workflow run makes the same code emit checks-passed. Compaction and the affected agent turn completed normally.

Steps to reproduce

1. Watch a GitHub PR with watch_pull_request.
2. Run CI on its head commit.
3. Cancel or supersede the workflow run, leaving cancelled checks in the head commit's rollup.
4. Complete a replacement workflow run successfully on the same head commit with different job names.
5. Use a configuration where no checks are marked required in the returned detail, so all checks form the gate.
6. Allow the watcher to refresh.

Expected: Recognize the successful replacement suite and send a checks-passed wake without superseded cancellations blocking it.
Actual: Cancelled checks survive under their old names, passed remains false, and no success wake is sent.

A deterministic offline replay of the captured contexts reproduces this.

Version

0.1.6, confirmed by installed runtime and investigation evidence. Triage CLI: 0.1.0.

Environment

Ubuntu Linux x64, kernel 6.8.0-147-generic, Node.js v26.8.2. Linux T3 server watching a GitHub PR. Client device and application surface were not recorded.

Evidence

Offline replay, installed code + actual GitHub contexts:
{"checks":28,"failures":["api (ruff, mypy, pytest)","web browser tests (runner ${{ matrix.slice }} of 6)"],"passed":false,"wake":[]}

Same code + superseded workflow run excluded:
{"checks":26,"failures":[],"passed":true,"wake":["checks-passed"]}

FAIL: successful replacement full suite does not produce a checks-passed wake

Captured contexts were complete: pageInfo.hasNextPage=false.

Persisted state after CI finished:
snapshot.checksState="passing"
watch.failedChecks=["api (ruff, mypy, pytest)","web browser tests (runner ${{ matrix.slice }} of 6)"]
watch.passed=false
watch.passedChecks=[]
watch.owedChecks=[]
watch.checksAwaitedSince=null

Provider trace, 2026-11-03 UTC:
14:18:35.853 item/started contextCompaction
14:19:22.362 item/completed contextCompaction
14:19:58.525 turn/completed status=completed turnError=null

Watcher sync operations reported success after compaction, including 14:20:26.925 and 14:36:38.316 UTC.

Related issues

#17207 concerns premature success with overlapping same-named checks. This case instead retains superseded cancelled checks when replacement job names differ, blocking success. No exact duplicate or released fix was confirmed; API connectivity and source fetch failures limited upstream checks.

Fix applied or workaround

The user manually resumed the thread. No runtime changes, database writes, source patches, or service restarts were performed. Excluding the superseded run was an offline diagnostic comparison only.

Filed by

Codex, GPT-6.1-Sol, via t3 triage