[Bug]: PR watching misses replies after the first 10 comments in a review thread

[eimexdev]

Before submitting

• Searched existing issues and did not find a duplicate.
• Included enough detail to investigate the problem.

Area

apps/server

Steps to reproduce

Source-derived reproduction steps; not yet verified against a live PR:

1. Open a GitHub PR with an inline review thread containing 10 comments.
2. Start watching the PR with watch_pull_request and allow an initial sweep to complete.
3. From a different GitHub account, add an 11th comment to that same review thread.
4. Leave the T3 thread active and idle, without changing checks or introducing merge conflicts.
5. Allow subsequent watch sweeps to run.

Expected behavior

The new reply wakes the agent once, just like replies within the first 10 comments.

Actual behavior

The watcher never sees the reply and does not wake the agent.

The initial GitHub activity query requests comments(first: 10) for each review thread. It returns pagination cursors, but PullRequestWatchReactor evaluates only the initial activity response and never follows those cursors. Every sweep therefore reads the same first 10 comments.

This limit applies per inline review thread, not across the entire PR.

Impact

Minor bug or occasional failure.

Feedback in longer review discussions can silently go unnoticed while the PR remains marked as watched.

Version or commit

main at 2a455570e6ee70a59241c30126b50c7df1696a6a, following PR #15057.

Environment

GitHub PR monitoring through Orchestrator V2. Investigated by source inspection on Linux with Node.js v24.21.0; no live provider reproduction performed.

Logs or supporting evidence

• Initial query requests 10 comments per thread.
• Watcher evaluates initial activity without following comment cursors.
• Existing service can fetch continuation pages.

A focused fix could reuse the existing comment pagination service during watch sweeps while preserving lazy loading in the UI. Incomplete pagination must not advance the comment watermark, which could otherwise cause unread replies to be skipped permanently.

Workaround

Check longer review threads manually on GitHub. Restarting the watch does not remove the pagination limit.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Triage

Thanks for the careful source walk-through, @eimexdev. This is a real gap on current main (f90b77d809), and it's the same code on the commit you cited (2a455570e6). I didn't find a duplicate or a fix PR.

watch_pull_request should wake the agent when someone else comments. In a GitHub review thread, that stops working after the 10th comment, and restarting the watch doesn't help.

What happens

The activity query in apps/server/src/pullRequest/gitHubPullRequestJson.ts asks for only the first page of each thread:

comments(first: 10) {
  totalCount
  pageInfo { hasNextPage endCursor }
  nodes { id author { __typename login avatarUrl } body createdAt url ... }

That cap is on purpose. Asking for a hundred comments on each of a hundred threads made GitHub reserve 10,000 nested rows and charge 104 points, so a test keeps reviewThreads(first:) * comments(first:) at or under 1,000 in REVIEW_THREADS_GRAPHQL_QUERY. The rest of a long thread comes from a separate query, REVIEW_THREAD_COMMENTS_GRAPHQL_QUERY, which PullRequestService.threadComments exposes. The UI calls it when someone opens the thread, but the watch sweep never does.

listReviewThreadComments pages through the threads themselves but not through a long thread's comments. A thread with hasNextPage comes back with nextCommentsCursor and only its first page of comments, and the result is marked truncated. The test "leaves a long thread paged until the reader asks for more" pins that behavior.

PullRequestWatchReactor then treats that partial read as complete (around line 163):

const degraded =
  activity.commentsTruncated &&
  !activity.reviewThreads.some((reviewThread) => reviewThread.nextCommentsCursor !== undefined);
const report = evaluatePullRequestWatch(watch, detail, degraded ? null : activity.comments);

If the read is truncated and no thread has a cursor to explain it, the sweep holds remarks and tries again later. A long thread does have a cursor, so degraded is false and only its first 10 comments get evaluated. The 11th reply never shows up in that list, so it never wakes the agent. Issue comments and review bodies aren't affected, because gh pr view --json comments,reviews follows its own cursors. Only the inline thread read stops short.

There's also a watermark problem. remarksThrough advances to the newest remark the sweep actually saw. A later issue comment, review, or reply on a short thread can push it past the reply that was never read. Remark ids are only kept for that boundary timestamp, so even a later complete read would skip the reply. You're right that any fix has to respect the watermark.

Likely fix area

One option is to page unfinished threads during the watch sweep using the existing threadComments read. Raising comments(first:) on the initial query would bring the 104-point cost back. The sweep could follow a cursor only for threads whose loaded comments are fewer than commentCount. It would also hold remarksThrough until those threads are fully read, or until it can show nothing unread sits after the watermark. If a follow-up page fails partway, it could take the same path as today's unexplained truncation: pass null remarks and wait.

Most pull requests never have an 11-comment thread, so the extra request would be rare. On an active watch it would still run once a minute, though, so it carries a cost, and documenting the cap is another option.

Until then, a reply past the 10th comment in a single review thread won't wake the agent, so it's worth checking those threads on GitHub.

A maintainer will decide on the fix direction.