Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Automatic review answered goes RED on an installation rate-limit 403 — answered PRs stop draining

Open
  • Is something wrong?
#7,187 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp, github-actions
Domain
ci-cd, devtools

Research direction

Start with check-review-answered.py and the Review answered workflow that runs it; the issue identifies the installation rate-limit 403/429 path and the x-ratelimit-reset header. Trace how API errors become check verdicts, then inspect the event triggers and concurrency settings that start duplicate runs. Done means transient rate limits do not create a terminal failure and review replies no longer trigger a burst of full checks.

Written by the indexing model from the issue text.

Description

bug sev:H

Symptom (2026-10-25): the fleet's PR queue stopped draining. Core #7173, #7180 and #7178 had every review thread answered and green tests, yet the required Automatic review answered context stayed failure, so mergeable_state read blocked.

The check's own verdict (#7173, lane / Automatic review answered, workflow Review answered, run 40187547005):

##[error]check-review-answered cannot read the review of #7173, so it cannot say it was answered: GET repos/Systemorph/MeshWeaver/pulls/7173 failed (1): gh: API rate limit exceeded for installation … 2026-10-25 11:17:56 UTC (HTTP 403)

What used up the budget: answering a review fires both a pull_request_review and a pull_request_review_comment event per reply. #7180 answered 27 threads at about 11:18Z, which started roughly 60 Review answered runs (most cancelled by the concurrency group, but each started and made REST calls), at the same time as other PRs' rounds. The installation's REST budget ran out between 11:17 and 11:21Z, and every check that ran in that window recorded a red verdict.

Why this is a defect and not just bad luck: an unreadable review is an availability failure, not an unanswered verdict. Recording it as a terminal failure leaves the PR blocked until somebody notices and re-runs it. Nothing re-runs it automatically, because refresh only follows a GREEN verdict. #6215 (closed) fixed the same problem for the carry-over check ("back off until the reset"). check-review-answered.py still fails on the 403.

Fix shape:

  1. On a rate-limit 403/429, wait until x-ratelimit-reset within the job's cap, or leave the check pending/neutral and schedule one retry after the reset. Never record a terminal failure.
  2. Stop a burst of N replies from costing N×2 full runs. Either debounce on the head (one judgement per head per settle window), or listen to one of the two events only. Plugins#3101 made exactly that change for the Plugins stage-advance lane.

Interim: I re-ran the three runs above by hand at 11:47Z, which is legitimate: the state the check reads did change and the red was infrastructure.

Not established: whether the budget that ran out was GITHUB_TOKEN's per-repo limit or the GitHub App installation's shared limit. The message says "installation", and both are installation tokens. Whether Plugins' review-answered lane reds the same way: its PRs I looked at were blocked on genuinely unanswered threads.

🤖 Generated with Claude Code

Dominant language
C#
Stars
12
Forks
5
Avg merge
6h 37m
Merged PRs (30d)
929

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Systemorph/MeshWeaver

All issues in Systemorph/MeshWeaver

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.