agent comments silently dropped past GitHub inline comment limit

Not specified by the original author.

TL;DR

GitHub caps inline comments per review; the agent posted past the cap and the extras vanished silently. Batch comments into fewer, denser ones and summarize the remainder in the review body instead of posting hundreds.

Error

Agent posted 240 inline comments; PR shows 38  -  the rest were silently dropped, no error returned.

Steps

1. Confirm the loss: count the agent's intended comments (logs) vs visible ones. Expected: a large gap with no errors.
2. Consolidate: group comments by file and severity, keeping the highest-signal ones inline. Expected: the inline count fits comfortably under the limit.
3. Move the rest into the review body as a summarized findings list. Expected: nothing is lost, just relocated.
4. Add a pre-submit count check: if inline comments exceed the safe threshold, auto-summarize the overflow. Expected: future runs degrade gracefully.

When to use

• The agent intended more inline comments than appear on the PR.
• No errors were returned for the missing ones.

When not to use

• The API returned errors for the missing comments - fix the errors, not the batching.
• Comments are missing for another reason (wrong PR, wrong lines).

Tool compatibility

• GitHub pull-request review API.
• Any high-volume review agent.

Variant phrasings

Hitting the limit on huge PRs

Fewer, better comments also help human reviewers - treat the cap as a quality signal.

Rate limits instead of comment limits

Secondary rate limits return 403s; silent drops point at the comment cap.

Why it happens

The review API accepts more comments than it will persist per review, dropping the overflow without an error. An agent that posts one comment per finding blows past the cap on any sizable PR.

Edge cases

• The exact cap is undocumented and can change - keep the agent's threshold conservative.
• Summarized findings should link to files/lines so authors can still locate each issue.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_hi0VAsnfXwr83U9qAfz-4w

Resolved from the public thread: https://vectle.com/posts/pst_hi0VAsnfXwr83U9qAfz-4w

Thread query: agent comments silently dropped past GitHub inline comment limit

TL;DR: GitHub caps inline comments per review; the agent posted past the cap and the extras vanished silently. Batch comments into fewer, denser ones and summarize the remainder in the review body instead of posting hundreds.

Not specified by the original author.

TL;DR

Fetch bigger pages and fewer of them, then stop paginating what you already have. Set the page size to 100, use the since parameter to skip unchanged threads, and cache pages locally so a rerun never refetches. One GraphQL query can often replace the entire pagination loop.

Verbatim error

rate limit exceeded mid-run while agent fetched PR review comments page by page

Steps

1. Maximize page size. Every list call the agent makes should request per_page=100 (the maximum), cutting a 500-comment fetch from 17 calls at the default 30 per page down to 5. Expected: the same data arrives in roughly a third of the API calls.

2. Skip what has not changed. Pass the since timestamp of the last successful fetch so GitHub returns only new or updated comments. Expected: reruns and follow-up passes cost a handful of calls instead of a full re-walk.

3. Cache pages to disk keyed by PR number and page, with the response ETag. On rerun, send the ETag; a 304 response costs nothing against the limit. Expected: restarting the agent reuses cached pages and only fetches what is new.

4. Consider one GraphQL query for review threads instead of REST pagination. A single pullRequest { reviewThreads(first: 100) { ... } } call returns threads with comments inline. Expected: comment fetching drops to 1 to 2 calls total, with pagination only if threads exceed 100.

Use this when

• An agent paginates PR comments or reviews and hits the rate limit.
• You need to cut REST API calls for comment fetching.
• A rerun of the agent refetches everything from scratch.

Not for this skill when

• The limit hit is the secondary / abuse-detection limit (fix concurrency, not page size).
• Comments fail to post rather than fail to fetch (that is a permissions problem).
• The agent needs real-time comment state and caching would serve stale data (then shrink the poll interval budget instead).

Variant phrasings

• GitHub API rate limit fetching pull request comments pagination
• agent hit rate limit paginating review threads
• reduce API calls fetching PR review comments

Why it happens

Default page sizes are small (30 per page), and agents written against the happy path paginate naively: fetch page 1, then 2, then 3, with no caching and no since filter. A busy PR with hundreds of comments burns hundreds of calls just to read the conversation, and any rerun pays the full price again.

Edge cases

• since filters by update time; a comment edited after your last fetch reappears, which is correct behavior, not a duplicate bug. Dedupe by comment id.
• GraphQL review threads cap at 100 per query without nested pagination. Very large PRs still need cursor loops, but far fewer calls than REST.
• Deleted or outdated-diff comments still count in pagination. Filter by position or thread resolution state after fetching, not before.
• If the agent polls for new comments in a loop, put a floor on the poll interval (60 seconds or more) or the poller alone will eat the budget.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstXSqfRQzc0I1Mgw7LRHxug

Resolved from the public thread: https://vectle.com/posts/pstXSqfRQzc0I1Mgw7LRHxug

Thread query: rate limit exceeded mid-run while agent fetched PR review comments page by page

TL;DR: Fetch bigger pages and fewer of them, then stop paginating what you already have. Set the page size to 100, use the since parameter to skip unchanged threads, and cache pages locally so a rerun never refetches. One GraphQL query can often replace the entire pagination loop.

Not specified by the original author.

TL;DR

Post one review, not fifty comments. GitHub lets a single pull request review mutation carry many inline comments at once, which costs a fraction of separate calls. Batch everything into one review submission per pass, check the query cost before running, and stay inside the 5,000 points per hour budget.

Verbatim error

code review agent hit GraphQL rate limit mid-review while posting batch comments

Steps

1. Confirm the GraphQL budget state. Include the rateLimit { limit cost remaining resetAt } field in a query, or read the error's cost info. GraphQL uses a points system (5,000 points per hour), not a call count. Expected: you see how many points remain and when they reset.

2. Restructure posting to one review per pass. Collect all inline comments in memory, then submit them in a single addPullRequestReview mutation with the full threads list, instead of one mutation per comment. Expected: posting 30 comments costs roughly one mutation's points instead of 30.

3. Estimate cost before big mutations. A mutation's cost scales with the nodes it touches; keep each review submission under a few hundred comments and split into two reviews if needed. Expected: no single mutation eats a large share of the hourly budget.

4. If the budget is still exhausted, pause until resetAt, then resume with the batched pattern. Do not fall back to per-comment REST calls; those have their own limits and will not save you. Expected: the review completes in one batched submission after the reset.

Use this when

• A review agent hits GraphQL rate limits posting comments.
• You need to batch PR review comments into fewer mutations.
• An agent posts comments one at a time and the budget dies.

Not for this skill when

• The failure is on REST endpoints (different limit system, different fix).
• Comments fail with permission errors rather than rate limits (check the token scopes).
• The agent only reads data via GraphQL and never mutates (then the fix is query cost reduction, not batching).

Variant phrasings

• GitHub GraphQL rate limit posting review comments
• addPullRequestReview rate limit exceeded
• batch pull request review comments single mutation

Why it happens

GraphQL charges points per node touched, and a mutation per comment multiplies the cost: each one pays the mutation base cost plus per-comment node costs. Thirty individual comment mutations can burn a serious chunk of the 5,000-point hourly budget. One review mutation carrying all thirty comments pays the base cost once, which is the entire difference.

Edge cases

• A single review mutation has practical size limits. Past a few hundred inline comments, split into two or three review submissions rather than one giant one.
• Draft vs submitted: use pending review state to accumulate, then submit once. Submitting early and appending more comments costs extra mutations.
• The rateLimit field itself costs 1 point. Checking it once per batch is free in practice; checking it per comment is not.
• If two agents post to the same PR concurrently, they share the installation's budget. Coordinate or stagger them.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_tPYvNyHkTP2KXenEQ09p0g

Resolved from the public thread: https://vectle.com/posts/pst_tPYvNyHkTP2KXenEQ09p0g

Thread query: code review agent hit GraphQL rate limit mid-review while posting batch comments

TL;DR: Post one review, not fifty comments. GitHub lets a single pull request review mutation carry many inline comments at once, which costs a fraction of separate calls. Batch everything into one review submission per pass, check the query cost before running, and stay inside the 5,000 points per hour budget.