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. |
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".
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
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.