[griffemi]

Problem

The watch reads PR detail (checks, head, mergeability) and PR activity (comments) together. If the activity read fails, the whole sweep is treated as failed, so check results that were read successfully are thrown away. A check finishing during a period of comment-read errors does not wake the agent.

Change

The detail read decides whether the sweep succeeded. An activity failure is logged, clears the cached comment tail for that PR, and leaves activity unavailable for that sweep; check, conflict and head updates still apply. Interrupts still propagate, and permanent detail-read failures are handled as before.

Scope and approval

A small, focused fix for an obvious failure-isolation defect in the existing check wakes. It adds no wake reason, alert policy or setting.

Verification

• runtimeLayer.test.ts "wakes for checks that complete after…": on main it observes one notification instead of two (expected [...] to have a length of 2 but got 1), the completion wake is missing; passes with the fix, along with the existing repeated host-read-failure cases (6 focused tests).
• vp run check:changed passes.

Not checked: a live run where GitHub's comments endpoint fails.

Code written by gpt-6.1-sol in Codex (via T3 Code); split, reviewed and filed by Claude Opus 5.5 in Claude Code.

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at 1c70fa3

Macroscope's review found this PR approvable — PR check updates can continue when comment reads fail, while failures are logged and comments remain eligible for retry. The change is confined to watch error handling and preserves existing detail-failure safeguards.

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

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

readGroup now handles pull-request detail and activity read results separately. Non-interruption activity failures no longer suppress successful detail results. The runtime test covers an activity failure during the successful-check sweep.

Changes: Pull-request watch read handling

Layer / File(s)	Summary
Separate activity failures from detail-read handling apps/server/src/orchestration-v2/PullRequestWatchReactor.ts, apps/server/src/orchestration-v2/runtimeLayer.test.ts	The detail read controls read-failure handling. Non-interruption activity failures clear cached thread tails, are logged, and allow processing to continue without activity data. The runtime test enables an activity failure before the successful-check sweep.

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Possibly related issues

• [Bug]: Unreadable PR watch repeatedly asks to re-arm after the PR is closed #27945 — The change prevents activity-read failures from failing the sweep, but it does not add closed-pull-request terminal handling.

Suggested reviewers: yash-singh1, juliusmarminge

Merge Risk: Minimal · up to 1c70f

Check updates can proceed when activity reads fail. No merge-blocking risk was established.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title names the main change: a failed comments read no longer hides PR check updates. The raw summary and PR objectives both describe a detail-read-controlled sweep that keeps check, conflict and …
Description check		The description follows the template's Problem, Change, Scope and approval, and Verification sections. The Problem and Change sections explain the defect and the fix clearly. The Scope section says th…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Title check

Explanation

The title names the main change: a failed comments read no longer hides PR check updates. The raw summary and PR objectives both describe a detail-read-controlled sweep that keeps check, conflict and head updates when activity reads fail. The title is concise, follows the conventional commit form, and is specific enough for a teammate scanning history.

Full details: Description check

Explanation

The description follows the template's Problem, Change, Scope and approval, and Verification sections. The Problem and Change sections explain the defect and the fix clearly. The Scope section says the change is a small, focused fix for an obvious defect and adds no wake reason, alert policy or setting, but it does not link a triaged issue or maintainer approval, and the template asks for that or an explicit exemption rationale. The Verification section gives a focused test with observed before and after results and names an unchecked item. It does not mention the agent model and harness in the template's required form, though the author does name the tools used, so that item is not missing. The description is mostly complete, so the check passes.

Finishing Touches

Generate unit tests (beta)

• Create a new PR

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

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 7a328c4
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: 706ed692-eb00-4e25-94be-a081148e776d

Commits

Reviewing files that changed from the base of the PR and between 7a328c4 and 1c70fa3.

Files selected for processing: 2

• apps/server/src/orchestration-v2/PullRequestWatchReactor.ts
• apps/server/src/orchestration-v2/runtimeLayer.test.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.

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

Verified in a real dev environment

verified unchanged head 1c70fa3e79cb33c7cda14185bea6b9f067dad50c on linux with playwright and /usr/bin/google-chrome, app-created project/thread data, and real codex gpt-6.1-sol turns.

on github/main (f12bb6229c), a transparent network proxy dropped only this pr's comments requests while forwarding real host responses for details and checks. four sweeps logged pull request watch check failed; the fresh watch stayed at passed=false, headSha=null, with no check wake despite successful status reads.

after stopping main, the exact pr head ran against a copy of that same app-created state. with the identical network failure, it logged pull request watch activity read failed, processed the live completed checks, displayed #33452: checks passed, and resumed the real codex turn. the agent reported the check wake.

nearby behavior: rewatching did not duplicate the check wake during another comments failure. after restoring network access, the next watch sweep successfully read comments without a duplicate wake; the timeline loaded the two real comments. the ui's stop control removed the watch.

blacksmith passed the six focused existing runtime tests and vp run check:changed b8c2cfad6b33 (format, lint, knip, graphql, affected typechecks, and adjacent tests). no code changes were needed.

command transcript

Not verified

no new live ci pending-to-success transition was triggered; the runtime case used completed checks first observed by a fresh watch. the focused existing test covers completion after the no-checks notice. the host was git.cafe; a github-specific outage was not exercised. native desktop/mobile, remote/tunnel connections, live provider cancellation, and permanent detail-read failures were not exercised here. permanent failure cases passed in the existing focused tests.