[AdeyaDev]

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 0be9991

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

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

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

readGroup handles pull-request detail and activity reads independently. Activity-read failures no longer prevent successful detail results from reaching watch evaluation. 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	Detail-read failures retain their existing handling. Activity-read failures clear cached thread tails, are logged when they are not rate limits, and allow detail-derived watch evaluation 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

Suggested reviewers: juliusmarminge, yash-singh1

Merge Risk: Minimal · up to bb28f

This change keeps PR check, conflict and head updates flowing when the comments read fails, and it logs the failure. The change is small and covered by a focused test and passing CI. No merge-blocking risk was found.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title names the main change: a failed comments (activity) read no longer hides PR check updates. The raw summary confirms that a failed activity read no longer fails the whole group read, and deta…
Description check		The description follows the template sections. Problem explains that a failed activity read discards successful check results. Change explains that the detail read decides sweep success and an activit…
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 (activity) read no longer hides PR check updates. The raw summary confirms that a failed activity read no longer fails the whole group read, and detail-derived checks, head, and conflict data still reach the evaluator. The title follows the conventional commit format used in the repository template.

Full details: Description check

Explanation

The description follows the template sections. Problem explains that a failed activity read discards successful check results. Change explains that the detail read decides sweep success and an activity failure is logged and clears the cached comment tail. Scope explains the fix is small and bug-focused, but it does not link an issue or state why no issue is needed beyond calling it an obvious defect. Verification lists focused tests and a repo check, names the unchecked live GitHub failure case, and includes the model and harness attribution. The Scope section lacks an issue link or a maintainer request reference, which the template asks for.

Resolution

Optionally link the issue that shows the bug, or state briefly why a small obvious fix needs no issue. The Verification section already meets the template requirements.

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: 49eb9c8
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: 440475e4-0939-4eda-b4fc-efe1b9f55637

Commits

Reviewing files that changed from the base of the PR and between 314e1fa and bb28fd3.

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; 9 remain after this review.

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

merged current github/main (a6c26d3e775e) into the existing contributor branch without rebasing. head: 314e1fa5d87c172dd32ae4db87a15cc1f128ded9. the merge was clean; no additional code changes were needed. the pr remains two files, +26/-17 against main.

verified this head with blacksmith vp run check:changed a6c26d3e775e08ad5f455dc65e07b05fe1627718: format, lint, knip, generated graphql, affected typechecks (3 packages), and 153 tests passed. approved the pending fork workflows; github ci now passes, including all eight server shards, build/typecheck, lint, and the final Check job. github reports mergeable: true, mergeable_state: clean; no unresolved review threads. both independent read-only reviewers approved this head. the task-owned blacksmith worker is stopped.

reviewed the two unverified bot suggestions: checks-only wakes already occur for incomplete comment pagination and do not claim comments were read; typed failures and defects enter the same Exit.isFailure recovery branch, so the existing fixture exercises the changed path. neither requires widening this merge-only pass.

no new browser/provider run was performed for this merge-only pass. the prior live verification and evidence below apply to the original contributor head.

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.

Dismissing prior approval to re-evaluate 0be9991

[coderabbitai]

Additional comments: 2

apps/server/src/orchestration-v2/PullRequestWatchReactor.ts-524-526: 1

524-526: Major · Functional Correctness · Heavy lift

Unverified finding
Verification ran but could not confirm this finding. It is shown for review, not as a verified issue.

Tell the agent when the comment read failed.

If checks pass while activity is unavailable, the wake omits comments without saying they were unavailable. pullRequestWatchMessage tells the agent to unwatch when handing work back, so it can stop the watch before missed review comments are recovered. Include the activity failure in the existing wake text without suppressing the check update. (raw.githubusercontent.com)

apps/server/src/orchestration-v2/runtimeLayer.test.ts-4367-4367: 1

4367-4367: Major · Maintainability & Code Quality · Quick win

Unverified finding
Verification ran but could not confirm this finding. It is shown for review, not as a verified issue.

Test a typed activity failure.

The service returns host-read failures as PullRequestError, but this fixture produces a defect. A regression that handles defects but propagates typed failures would still pass this test. Use a representative PullRequestOperationError with Effect.fail.

Based on learnings, use Effect.fail for expected recoverable errors and Effect.die for unrecoverable defects.

Source: Learnings

Review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: f31ce3e
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: 99ebaabd-ca26-4422-9268-c168d2d47073

Commits

Reviewing files that changed from the base of the PR and between 1c70fa3 and 0be9991.

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; 9 remain after this review.

[juliusmarminge]

Evidence

Environment: real web client and server per commit, fresh databases, Chromium 151 on Linux, 1440×900, light theme, Replay agent. Synthetic GitHub responses make the outage and CI transition repeatable.

Steps on both sides: link the synthetic PR; start recording before enabling watch; allow a successful activity sweep; enable activity HTTP 503 failures; wait for an outage sweep; open the PR Summary panel and confirm its error; complete CI while retaining the outage; wait for two scheduled watch sweeps; capture stable frames.

Before	After
49eb9c8adc	bb28fd36d7
Full before recording	Full after recording

Both recordings begin before watch is enabled. Both detail panels are opened after an outage sweep and visibly show the same activity HTTP 503 error. Base remains waiting after two completed-check sweeps; head receives the checks-passed wake and runs the second replay turn.

Detailed steps and reproduction instructions · Browser driver and seed · API fixture · Server launcher

Before read log · After read log · Before interaction timestamps · After interaction timestamps

Not shown:

• Comment watermark preservation with non-empty or paginated activity was not separately demonstrated; the fixture has empty baseline comments followed by a full activity outage.
• Live GitHub CI and fingerprint-based read skipping were not exercised. Synthetic API responses supply one watched PR and an unavailable fingerprint, forcing full reads.