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

Review carry-over check aborts on a GitHub API rate-limit 403 instead of backing off until the reset window

Open
  • Is something wrong?
#6,215 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
Clearly specified
Activity status
Active
Tech stack
csharp, github
Domain
api, backend, observability

Research direction

Start with the Carry routine in Hosting/PlatformBuildInbox/Source/* and the reply selector identified as throwing in Hosting_PlatformBuildInbox.cs; then read TriageActions and GitHubAppTokenService to understand where REST reads and installation tokens are handled. Compare with ProviderRefusalOf for the existing provider-refusal pattern. Done means transient GitHub rate-limit refusals are handled with bounded backoff and the relevant behavior is covered by tests.

Written by the indexing model from the issue text.

Description

bug sev:M

What is failing

The pull-request steward's review carry-over check — the feature where a clean merge of the base branch carries the reviewed verdict to the new head without a fresh review (Plugins #2978) — reads the head's check runs through the systemorph-com GitHub App installation token. When GitHub refuses that read with HTTP 403 (primary rate limit exceeded for the App installation), the reply handler throws InvalidOperationException ("the head's check runs could not be read (403): …") and the item falls back to being reviewed as usual. The fallback is correct and safe; the defect is that a routine, transient GitHub rate-limit refusal is treated as a check failure at ERROR level instead of being retried after the reset window.

Probable cause — high confidence

The 403 body is GitHub's own primary-rate-limit refusal naming the App installation. The steward reads GitHub through REST only, polling every PR of the silo (webhook-driven intake plus the 10-minute PullRequestSweep) plus per-head carry-over reads, all under the one installation token's hourly budget — so the budget can be exhausted, and any read in that window (this check, gate watching, posting reviews) fails. The carry-over reader has no handling for 403/429: it does not respect x-ratelimit-remaining/x-ratelimit-reset and does not back off and retry.

This is the same failure class the platform already fixed for the model provider after the 2026-10-04 outage (a quota refusal classified as "Unknown" and posted RED): ProviderRefusalOf (Plugins #2788/#2831) now reads a provider quota/credit/rate refusal as an infrastructure round. That classifier covers OpenRouter-side refusals only — the GitHub REST side has no equivalent.

Impact

One occurrence, one pod, one PR: the carry-over optimization was lost for that head and an ERROR was logged; the ordinary review path took over, so nothing user-visible broke. The signal matters more than the instance: the App installation's hourly rate budget was exhausted once, and in such a window every steward GitHub call fails the same way — including posting reviews and the required internal-review check run, which would hold every merge in the silo until the window resets. Not a duplicate of any known incident; the 2026-10-05 rate-limit fix (Governance/PullRequestSteward §14) is the closest relative and covers a different provider.

Where to look

  • The reply selector that throws: ReviewCarryOver.<>c.<Carry>b__26_3(RestReply reply) in the generated Hosting_PlatformBuildInbox.cs — the Carry routine in the Hosting/PlatformBuildInbox module (source trees under Hosting/PlatformBuildInbox/Source/*, sibling of ReleaseFollowThrough).
  • TriageActions / GitHubAppTokenService on the item's hub, where installation tokens are minted and REST reads are issued — the right place to read the rate-limit headers and back off.
  • Suggested fix shape, mirroring ProviderRefusalOf: classify a 403/429 rate-limit refusal from GitHub REST as an infrastructure condition, retry the read once after x-ratelimit-reset (bounded), and count near-limit reads so saturation of the installation budget is visible before it bites the review path.
Evidence
Fingerprint ce4f2cc9053ed862
Category PlatformBuildInboxWatcher
Severity Error
Exception System.InvalidOperationException
Top frame ReviewCarryOver.<>c.<Carry>b__26_3(RestReply reply)
Namespace memex
Pods memex-portal-deployment-6bcdbb54fc-g9gh4
Occurrences 1
First seen 2026-10-06 21:45:43Z
Last seen 2026-10-06 21:45:43Z
Routing not determined — no configured route matches the category PlatformBuildInboxWatcher. This repository is the configured fallback, not a finding about who owns the fault; the category names the LOGGER, which may not be the subject.
Recent log lines 
2026-10-06 21:45:43Z memex-portal-deployment-6bcdbb54fc-g9gh4 fail: PlatformBuildInboxWatcher[0]
      [Steward] Systemorph/MeshWeaver.Plugins#3031 at 2a079e4447: the review carry-over check failed — reviewed as usual
      System.InvalidOperationException: the head's check runs could not be read (403): { 	"message": "API rate limit exceeded for installation ID 161076693. If you reach out to GitHub Support for help, please include the request ID 1819:99D9:7A91C:91BBB:6AC56C07 and timestamp 2026-10-06…
         at ReviewCarryOver.<>c.<Carry>b__26_3(RestReply reply) in /tmp/MeshWeaver/.mesh-cache/Hosting_PlatformBuildInbox.cs:line 25198
         at System.Reactive.Linq.ObservableImpl.Select`2.Selector._.OnNext(TSource value)

Opened automatically from Admin/_LogIncident/ce4f2cc9053ed862. Recurrences are folded into this issue rather than opening new ones.
It also stands for the whole log site 00974a9bde1ef71e: other fingerprints of this site fold in here as comments rather than opening tickets of their own.

Dominant language
C#
Stars
12
Forks
5
Avg merge
3h 53m
Merged PRs (30d)
968

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.