fix: bug-PR merge train batch 7 (multi-account OAuth 429 budget with a per-request ceiling)

[lidge-jun]

Summary

Batch 7 of the bug-PR merge train: one carried fix plus a security follow-up. The carried commit keeps its original author and a Co-authored-by trailer.

PR	Change	Author
#5916	Multi-account OAuth pools (Google Antigravity and other generic OAuth providers) stop starving on transient 429s. Before, the first account used up the request's send budget and the other eligible accounts were never tried. Now the ingress send budget funds each eligible account's normal three-send ladder, the rotation ceiling is snapshotted before cooldown writes can shrink it, and same-provider auth recovery keeps the physical target. Closes #5880.	@codingbooo

Integration commit 32be95be75: an independent security review of #5916 found that the allowance and hop limit both scaled with the enrolled roster and had no ceiling. With 100 accounts, one request could make 300 upstream sends and spread a 429 storm across the pool. GENERIC_OAUTH_MAX_ACCOUNTS_PER_REQUEST = 6 now clamps the roster snapshot in request-transport.ts, and the clamp is repeated inside expandInferenceOAuthSendBudget, so the default ingress ceiling is 18 sends whatever the roster size (it was 4 before #5916). Explicit caller budgets are unchanged. A new case enrolls eight accounts and expects exactly 18 sends over the first six accounts; without the clamp it sees 24. The docs and structure/transports/ state the cap.

The batch also adds the merge-train roadmap and the batch plan under devlog/_plan/260926_bug_train_6/, which record a decision for every open bug-labelled pull request.

Verification

• bun x tsc --noEmit: exit 0. bun run structure:check and bun run privacy:scan: pass.
• fix(server): balance multi-account OAuth 429 retries with send budget #5916 suites plus layout, file-size and core/Lab boundary guards: 139 pass, 0 fail (8 files). The eight-account case fails without the clamp (24 sends instead of 18).
• Adjacent OAuth and failover suites (adapter-event OAuth failover, pool-kernel generic sweep, Retry-After 429, key failover e2e, Kiro 401 replay, combo failover e2e): 272 pass, 0 fail.
• Security review: the first independent review of fix(server): balance multi-account OAuth 429 retries with send budget #5916 failed on the uncapped roster. A read-only audit of this plan passed, and a re-review of the final diff is recorded in a PR comment before merge.
• I did not run the full local suite; exact-head hosted CI covers the rest. A test 4/4 batch timeout in tests/cli/* (every file passed alone) was rerun.

Checklist

• Scope stays focused and avoids unrelated cleanup.
• Docs or release notes were updated when needed (docs-site providers reference, structure/transports/).
• Security-sensitive changes were reviewed for secrets, auth, and unsafe defaults (OAuth retry budget: independent security review, blocker fixed here).

Closes #5880

Co-authored-by: codingbo cnsdbo@163.com

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-26T10:29:07.167688Z	32be95b	PR opened

ℹ️ 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository: lidge-jun/opencodex/.coderabbit.yaml

Review profile: ASSERTIVE

Plan: Advanced

Run ID: 48c6f178-2d08-4e3a-a524-d28257cf6c1f

📥 Commits

Reviewing files that changed from the base of the PR and between 76b26a0 and 32be95b.

📒 Files selected for processing (22)

• devlog/_plan/260926_bug_train_6/010_roadmap.md
• devlog/_plan/260926_bug_train_6/020_batch7.md
• docs-site/src/content/docs/reference/configuration/providers.md
• scripts/test-layout/layout.json
• src/adapters/google-http.ts
• src/oauth/generic-account-failover.ts
• src/server/inference/context.ts
• src/server/responses/adapter-continuation.ts
• src/server/responses/adapter-dispatch.ts
• src/server/responses/passthrough-dispatch.ts
• src/server/responses/request-send-budget.ts
• src/server/responses/request-transport.ts
• src/server/responses/run-turn-execution.ts
• src/server/responses/sidecar-execution.ts
• structure/transports/inventory.md
• structure/transports/responses-failover.md
• structure/transports/responses-spend.md
• tests/fixtures/test-layout-expected.json
• tests/oauth/generic-oauth-failover.test.ts
• tests/oauth/oauth-account-attribution.test.ts
• tests/server/inference-send-budget.test.ts
• tests/server/server-google-antigravity-oauth-429-budget.test.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 5 remain after this review.

---

📝 Walkthrough

Walkthrough

The change adds a six-account cap for Generic OAuth failover and derives a request-specific rotation limit from the eligible roster. It expands eligible ingress send budgets, updates recovery send accounting, and uses the shared transient retry limit for Google HTTP requests. Tests and documentation describe the revised limits.

Changes

Generic OAuth failover and send budgets

Layer / File(s)	Summary
Request send budget and recovery accounting src/oauth/generic-account-failover.ts, src/server/inference/context.ts, src/server/responses/request-send-budget.ts, tests/server/inference-send-budget.test.ts, structure/transports/responses-spend.md	The request account cap is six. An unused ingress budget can expand according to the capped account count. Recovery reservations account for pending sends and reconcile physical target changes. Tests cover expansion limits, spent requests, and recovery accounting.
Request-local OAuth rotation limit src/server/responses/request-transport.ts, src/server/responses/adapter-continuation.ts, src/server/responses/adapter-dispatch.ts, src/server/responses/passthrough-dispatch.ts, src/server/responses/run-turn-execution.ts, src/server/responses/sidecar-execution.ts, tests/oauth/*, docs-site/src/content/docs/reference/configuration/providers.md, structure/transports/responses-failover.md, devlog/_plan/260926_bug_train_6/*	Request transport derives a rotation limit from the capped eligible roster. Responses recovery paths use that request-specific limit. Tests and documentation cover the updated behavior and limits. The batch plan records the carried work and related review and validation steps.
Google retry behavior and regression coverage src/adapters/google-http.ts, tests/server/server-google-antigravity-oauth-429-budget.test.ts, scripts/test-layout/layout.json, tests/fixtures/test-layout-expected.json, structure/transports/inventory.md, devlog/_plan/260926_bug_train_6/010_roadmap.md	Google HTTP retry checks use TRANSIENT_RETRY_MAX_ATTEMPTS. Antigravity tests cover transient 429 retries, the six-account cap, hard-quota responses, and explicit send ceilings. Test layout and inventory entries are updated; the roadmap records batch decisions and validation steps.

Priority: ➖ Normal

Estimated code review effort: 3 (Moderate) | ~25 minutes

Change: Bug fix · Severity of issue fixed: Medium

Sequence Diagram(s)

sequenceDiagram
  participant ResponsesTransport
  participant InferenceSendBudget
  participant GoogleHTTPAdapter
  participant GenericOAuthFailover
  ResponsesTransport->>InferenceSendBudget: Expand unused ingress budget for capped account count
  ResponsesTransport->>GoogleHTTPAdapter: Dispatch request with send budget
  GoogleHTTPAdapter->>GoogleHTTPAdapter: Retry transient responses within attempt limit
  GoogleHTTPAdapter->>GenericOAuthFailover: Return terminal 429 for account rotation
  GenericOAuthFailover->>GoogleHTTPAdapter: Dispatch with next eligible account

Loading

Suggested reviewers: luvs01, thisisjun786

Merge Risk: ⚪ Minimal · up to 32be9

The capped OAuth retry behavior has no identified merge-blocking issue after normal checks.

Security Architecture Review

Security architecture risk: 🟡 Moderate · up to 32be9

A rate-limited request can now retry across more accounts and make up to 18 upstream sends by default. The new cap prevents that allowance from growing with a larger account pool, but repeated requests could still put pressure on shared accounts. No exploit is verified.

Retained concerns

• Medium · security · inferred: Default recovery now permits one rate-limited request to use as many as six stored credentials and 18 upstream sends. If clients can repeatedly elicit transient 429s, the per-request cap alone does not contain pressure on the shared pool across requests; the effective aggregate control remains unestablished.

Security review details

Security Blast Radius

• inferred — An inference caller encountering transient upstream 429s can drive retries through up to six eligible credentials and 18 physical sends under the default ingress policy. The evidenced scope is one request and its configured provider pool; exposure across independent requests is not established.

Security Findings and Attack Paths

• inferred — The relevant abuse path is repeated client requests against a rate-limited provider, multiplying upstream traffic and touching more of the operator-enrolled pool. Whether a client can reliably induce the requisite transient responses, and what aggregate controls apply, remains unresolved; this is not a verified exploit.

Trust Boundaries and Controls

• observed — The server selects stored, eligible accounts rather than accepting a credential choice from the request. Send reservations charge the shared ledger before dispatch, and the tested explicit caller ceilings remain authoritative. These are countercontrols to unbounded per-request rotation, not evidence of an aggregate request-rate bound.

Hardening Proposals

• proposed — Verify aggregate recovery and admission limits for independent requests against the same OAuth pool, in addition to the new per-request bound. Also cover pre-send passthrough rebuild failure with an idempotent release of its pending hop reservation; the inspected failure path returns without an evident release.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 61.11% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 18 functions across 14 files. (8 skipped:…	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	The PR satisfies the coding requirements in [#5880]. src/server/responses/request-transport.ts snapshots the eligible roster, computes a request-local failover limit, caps the roster at six accounts…
Out of Scope Changes check	✅ Passed	The changes remain connected to [#5880]. The source changes implement OAuth retry ordering, roster snapshotting, physical-target preservation, per-request failover limits, and send-budget accounting. …
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly identifies the bug-train batch and the main change: multi-account OAuth 429 budgeting with a per-request ceiling. It is specific, concise, and directly related to the changeset.

Full details: Docstring Coverage

Explanation

Docstring coverage is 61.11% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 18 functions across 14 files. (8 skipped: 8 unsupported.)

• Fix all pre-merge checks with AI

✨ Finishing Touches 💡 2

📝 Generate docstrings 💡

• Commit to this branch
• Create a new PR

🛠️ Fix failing CI checks 💡

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

⚠️ Deterministic hygiene checks failed.

• missing_coauthor_credit — This pull request says it reimplements, supersedes, carries, or rebases another author's pull request, but no Co-authored-by trailer names that author. Prose in a commit body is not read by anything; the trailer is what GitHub counts. Add it to the description or a commit, or obtain attribution-approved. Paths: #5497, #5539, #5831.

[lidge-jun]

리뷰 · 우선순위 60 / 80

구글 안티그래비티처럼 로그인 계정이 여러 개인 OAuth에서, 429가 나면 다른 계정으로 바꿔 다시 보냅니다. #5916의 수정과, 계정이 많아도 한 요청이 무한정 두드리지 못하게 막는 상한을 한 묶음으로 가져왔습니다. 이슈 #5880을 닫습니다. 베이스는 dev입니다.

예전에는 요청 하나의 기본 예산이 4번이었습니다. 첫 계정이 429를 세 번 재시도하면 예산이 끝나서, 뒤에 있는 계정은 시도하지 못했습니다.

이 묶음은 보내기 전에 쓸 수 있는 계정 수를 고정합니다. 계정이 2개 이상이면 계정마다 3번을 줍니다. 한 요청이 세는 계정은 최대 6개입니다. 계정이 100개여도 기본 예산은 18번에서 멈춥니다. #5916만 있으면 계정 수 × 3이라 상한이 없었습니다. 계정이 하나면 예전처럼 기본 3번, 합계 4번입니다. 호출하는 쪽이 횟수를 직접 정한 경우와 콤보는 이 늘리기를 타지 않습니다. 같은 제공자 안에서 계정만 바꿀 때, 기록용 이름 때문에 다른 주소로 간 것처럼 세지 않습니다.

계획 문서는 #5497과 #5539를 이번에 가져오지 않고, #5831은 주인이 정할 일이라고 적습니다. 가져온 코드의 작성자는 codingbooo이고, 커밋과 본문에 Co-authored-by가 있습니다.

hygiene - 실패입니다. 봇은 #5497, #5539, #5831을 가져온 것으로 봅니다. 계획 문서에 그 번호가 있어서입니다. 그 세 PR의 코드는 이 diff에 없습니다.

src/server/inference/context.ts:41 - 늘리는 숫자는 기본 횟수와 총 횟수뿐입니다. 다른 주소로 갈아타는 한도(maxTargetTransitions, maxAlternateTargetSends)는 1 그대로입니다. 계정마다 주소가 같으면 6계정·18번까지 갑니다. 주소가 갈라지면 src/server/responses/request-send-budget.ts:333에서 두 번째 주소 전환이 막힙니다. 안티그래비티 테스트는 전부 같은 daily-cloudcode-pa.googleapis.com을 씁니다.

docs-site/src/content/docs/reference/configuration/providers.md:890 - 바로 위 문단은 한 요청이 최대 18번 나간다고 합니다. 주의 상자는 회전을 끄려면 enabled: false를 넣으라고 합니다. 818번째 줄과 표는 그 스위치가 429 회전을 끄지 않는다고 합니다. 끄는 방법은 두 번째 계정을 저장하지 않는 것입니다.

메인테이너의 판단이 필요한 지점

기본 상한 18번이 맞는지 정하면 됩니다. 주소가 계정마다 다른 풀도 6계정까지 가야 한다면 주소 전환 한도를 같이 올려야 합니다. #5916은 아직 열려 있습니다. 이 PR이 그 수정을 이미 품고 있어서, 둘 다 머지하면 같은 고침이 두 번 들어갑니다.

너의 추천

위생 검사부터 푸세요. 계획 문서를 고쳐 봇이 #5497, #5539, #5831을 가져온 PR로 읽지 않게 하면 됩니다. codingbooo 이름은 이미 있습니다. 주의 상자 890번째 줄은 818번째 줄과 같게 고치세요. 그다음 이 PR을 머지하고 #5916은 닫으면 됩니다. #5497, #5539, #5831은 이 묶음에 넣지 마세요.

이 댓글은 grok-bot이 작성했습니다

[github-actions]

✅ READY

• all PR quality gates passed.

Hygiene

✅ Deterministic PR hygiene checks passed.

[lidge-jun]

Security review record for this batch (OAuth retry budget, MAINTAINERS.md security-boundary rule).

1. First independent review of fix(server): balance multi-account OAuth 429 retries with send budget #5916 at its head: FAIL. The send allowance and hop limit scaled with the enrolled roster, and nothing capped them.
2. Plan audit of the fix in devlog/_plan/260926_bug_train_6/020_batch7.md: PASS, no blockers.
3. Re-review of the final diff at 32be95be75: PASS. The roster snapshot and ingress budget both cap funding at six accounts, so the default path makes at most 18 physical sends. All five generic OAuth 429 paths share the request-local hop limit and send budget. Each credential hop sends the new account's bearer with its own origin, project or Kiro context, and the review found no new credential exposure to other destinations or logs. The reviewer's focused run was 152 pass, 0 fail.