docs(issues): record the review-bot budget exhaustion and two local-environment findings - #2263
Conversation
…nvironment findings Three ledger inbox requests, each independently low-risk and separately revertible: - `#CCZ4HB` updated with hard numbers. Its prediction came true today on PR #2258: CodeRabbit reports 89 review attempts over 7 days, an allowance of 1 review per hour, and the organisation's usage spending cap reached. PR #2261 (which closes `#316`) is expected to land unreviewed as a result. Owns the contributing cause honestly — this session opened three PRs — and notes that two of the three were unavoidable, because a serialized reconcile needs its own fresh-base branch and an immutable review record cannot be edited in place, so PR bundling alone cannot fix this. - New P3: local process-spawn starvation. `gh --version` measured 1m37s on 2026-08-20 and 0.2s on 2026-08-22 with the binary unchanged; the decisive comparison is `node --version` moving 17s -> 0.08s over the same period, so it was never gh. A reboot clears it, it rebuilds with uptime and concurrent sessions, and the whole diagnostic is `time node --version`. Written down because the previous session mistook it for a broken tool and lost hours. - `#6GW95D` premise corrected: the Dev Drive was expanded and is now 27% used (59 GB free), so its capacity justification is gone. The real remaining issue is different — 18 of 30 directories under `.claude/worktrees/` are orphans git no longer tracks, which is the ambiguity that preceded two incidents where a sweep deleted an in-use worktree. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 33 minutes Limit details: You’ve used the included review currently available. Your 90 included PR review attempts over the past 7 days set your current allowance at 1 review per hour. Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab. How can I continue?Wait for the limit to reset, then comment An organization admin can change what happens after included review limits in Billing. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (7)
Comment |
CI triageCI failed on this PR. Automated classification of the 2 failed job(s):
Compared with main CI run #13077 (success). Classification is evidence routing, not permission to ignore a failure. Exact quarantined Playwright identities remain governed by the flake ledger. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3af177d5ec
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
1 participant
Summary
Three ledger inbox requests. No canonical-ledger edit and no reconcile here — these queue for the next one. Each item is independently low-risk and separately revertible.
#CCZ4HBupdated with hard numbers — its prediction came true today. That P1 warned that PR churn would exhaust the review-bot budget and leave PRs landing with no automated review. Observed directly on docs(ledger): supersede the Phase 5 review record with the verbatim gate output #2258: CodeRabbit reported89 included PR review attempts over the past 7 days, an allowance of1 review per hour, andYour organization has reached its usage spending cap. docs(issues): reconcile 19 queued ledger requests and close #316 #2261 — the reconcile that closed#316— was opened inside that window and landed without an automated review. The update owns the contributing cause rather than reporting it neutrally: this session opened three PRs. It also records why bundling alone cannot fix it — a serialized reconcile must be its own fresh-base branch and an immutable review record cannot be edited in place, so two of the three were structurally unavoidable. Two options are stated with a recommendation (raise the cap), and the row stops short of touching billing.gh --versionmeasured1m37son 2026-08-20 and0.201s / 0.262s / 0.278son 2026-08-22 with the binary unchanged (same 2.97.0, same local path, same 41,775,416 bytes, zero extensions). The decisive comparison is a binary unrelated togh:node --versionmoved17s → 0.080sacross the same period. Defender real-time protection was on in both readings, so it is not the discriminating variable. A reboot cleared it, and it rebuilds with uptime and concurrent sessions — one hour after the reboot the machine already showed 49nodeand 31claudeprocesses with 6.9 GB free of 32 GB. This matters becauseguard-push.mjscallsghseveral times per push, so the symptom is "every push takes 5–10 minutes" and the previous session spent hours treating it as a broken tool. The whole diagnostic istime node --version.#6GW95Dpremise corrected. It is written against a "51%-full Dev Drive";D:has since been expanded to 80 GB and now measures 27% used with 59 GB free, so its capacity justification is gone and it should not be actioned as a space emergency. The genuinely remaining issue is different and is recorded in its place: of 30 directories under.claude/worktrees/, 12 are registered worktrees belonging to live sessions and 18 are orphans git no longer tracks (16 completely empty). They cost almost nothing on disk — which is why nothing reclaims them — but they make the directory listing useless for telling live work from debris, and that ambiguity preceded two separate incidents in which a cleanup sweep deleted an in-use worktree mid-session. The row carries an explicit stop: never delete a directory that is ingit worktree list.Verification
Ledger-inbox-only change, so the gates that cover it were run directly rather than the full PR-local sweep, which is currently timing out on cross-worktree lock contention rather than on this diff.
npm run check:ledger-write-disciplinenpm run check:outstanding-issuesnpm run format(whole tree, result committed) andnpx prettier --checkon the three new records —All matched files use Prettier code style!Verification not run — lint, typecheck, unit suite, build, browser, and every eval: no executable scope. This diff adds three JSON inbox requests and nothing else.
Risk and rollout
issues:reconcile.git revertremoves the three files; nothing depends on them until reconciled.Notes
#CCZ4HBdescribes.phase-4-index-restoration-b0f4eastill cannot be removed: bothrmdirand PowerShellRemove-Itemreport it in use by a live session. No process was killed to force it.