fix(codex-manager): close the menu quota-refresh write races - #549

Summary

The focused follow-up promised on the #540 and #547 review threads: both quota-cache write races are pre-existing (they predate the login-machinery extraction; #547 moved them verbatim), fixed together here so the extraction stack stays zero-behavior-change.

Stacked on #547 (claude/audit-29-login-machinery), i.e. five deep: #525 → #535 → #540 → #547 → this. Merge in order; this PR then shows only the one fix commit.

Fix 1 — last-write-wins clobber (flagged on #540)

refreshQuotaCacheForMenu probed against a snapshot clone of the cache the menu had loaded, then saved that clone whole-file. Any entries a concurrent writer persisted while the probes ran — a user-triggered deep check, a second session — were silently discarded. The save now reloads the freshest persisted cache and re-applies this run's successful probe results onto it (using the same updateQuotaCacheForAccount logic, so unsafe-email pruning behaves identically), falling back to the clone if the reload fails. No blocking, no UX change — concurrent writers' entries simply survive.

Fix 2 — orphaned in-flight refresh (flagged on #547)

Leaving the dashboard (add-account, cancel, and the empty-storage onboarding path) abandoned a running background refresh whose cache save could land mid-flight against the subsequent persistAccountPool storage write (Windows EBUSY/EPERM on sibling files). The three exit paths now drain the pending refresh first. The wait is bounded by the per-probe HTTP timeouts, the chain never rejects, and menu actions are deliberately not drained — they stay instant; fix 1 makes their concurrent saves safe instead.

Changes

• lib/codex-manager/login-menu-data.ts: save-time rebase in refreshQuotaCacheForMenu (tracks applied (account, snapshot) pairs, re-applies onto a fresh loadQuotaCache() result).
• lib/codex-manager/login-flow.ts: drainPendingMenuQuotaRefresh helper called at the three dashboard exit points.
• test/codex-manager-login-menu-refresh.test.ts (new): pins the rebase (a concurrent acc_concurrent entry survives the save), the reload-failure fallback, no-save-when-unchanged, and the empty-storage no-op.
• test/codex-manager-cli.test.ts: the suite's loadQuotaCache mock now returns a fresh object per call, matching the real implementation's fresh disk read (the old shared singleton would leak the rebase mutation across loads); the two refresh-orchestration tests settle pass 1 via the statusMessage() observable (cleared in the same .finally that frees the pending slot) instead of relying on exact microtask counts, which the added rebase await shifted.

Validation

• npm run typecheck; eslint on all 4 touched files --max-warnings=0
• All 29 codex-manager suites: 484/484 passed (480 pre-existing + 4 new)

Risk / Rollback

The rebase only changes which base the whole-file save starts from; same-account results still take latest-wins (correct). The drain adds a bounded wait only on dashboard exit. Revert the single commit.

https://claude.ai/code/session_01XNtnkLbBiXZxfQQYLMpucB

Generated by Claude Code

note: greptile review for oc-chatgpt-multi-auth. cite files like lib/foo.ts:123. confirm regression tests + windows concurrency/token redaction coverage.

Greptile Summary

fixes two pre-existing quota-cache write races introduced during the login-machinery extraction: a last-write-wins clobber in refreshQuotaCacheForMenu (now rebases probe results onto a fresh disk load before saving) and an orphaned in-flight refresh on dashboard exit (now drained at all three loop-exit paths before returning to the oauth flow).

• login-menu-data.ts: tracks successful (account, snapshot) pairs, reloads the freshest persisted cache after all probes complete, re-applies the pairs onto it, and saves — concurrent writers' entries survive. the surrounding catch block is dead code because loadQuotaCache never rejects; on a real EBUSY reload it resolves to {}, silently losing non-probed entries instead of falling back to the snapshot clone as the comment promises.
• login-flow.ts: drainPendingMenuQuotaRefresh called at empty-storage, cancel, and add-account exits — prevents windows EBUSY/EPERM on the subsequent persistAccountPool write.
• test/codex-manager-login-menu-refresh.test.ts (new): four rebase scenarios; the reload-failure case mocks loadQuotaCache to reject, which the real implementation never does, so the fallback path tested here is unreachable in production.
• test/codex-manager-cli.test.ts: mock changed to fresh-object-per-call to prevent rebase mutation leak; refresh-settle guard switched to vi.waitFor on statusMessage() clearing for determinism.

Confidence Score: 3/5

the drain fix in login-flow.ts is safe and correct; the rebase logic in login-menu-data.ts has a silent failure mode when the disk reload encounters windows filesystem errors

the catch block surrounding loadQuotaCache() in the rebase path is unreachable — the real implementation swallows all errors and returns empty. on windows EBUSY during reload, cacheToSave becomes an empty base with only the fresh probes applied, silently discarding every pre-existing non-probed entry rather than falling back to the snapshot clone as documented. the test exercising this fallback passes only because it mocks a rejection that never fires in production.

lib/codex-manager/login-menu-data.ts (rebase catch block) and test/codex-manager-login-menu-refresh.test.ts (reload-failure test case)

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant Dashboard as DashboardLoop
    participant Refresh as refreshQuotaCache
    participant Disk as quota-cache.json
    participant Pool as persistAccountPool

    Dashboard->>Disk: loadQuotaCache initial
    Dashboard->>Refresh: fire-and-forget
    activate Refresh
    Refresh->>Refresh: probe accounts via HTTP
    Refresh->>Disk: loadQuotaCache rebase reload
    Disk-->>Refresh: fresh persisted state
    Refresh->>Refresh: re-apply snapshots onto persisted
    Refresh->>Disk: saveQuotaCache cacheToSave
    deactivate Refresh
    Dashboard->>Refresh: drain await pendingMenuQuotaRefresh
    Refresh-->>Dashboard: settled
    Dashboard-->>Pool: return add-account
    Pool->>Disk: persistAccountPool write no EBUSY race

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
lib/codex-manager/login-menu-data.ts:235-238
**dead catch — `loadQuotaCache` never rejects**

`loadQuotaCache` wraps every code path in a try/catch and returns `{ byAccountId: {}, byEmail: {} }` on any failure — it is documented never to throw. so this catch block is unreachable in production.

the real-world EBUSY-during-reload path is: `readCacheFileWithRetry` exhausts 5 attempts and throws → `loadQuotaCache`'s own catch swallows it and resolves to an empty object → `persisted = {}` → the rebase applies only this run's probes onto an empty base → `cacheToSave` silently drops every pre-existing entry in `nextCache` that wasn't re-probed this pass. that is the opposite of what the fallback comment intends ("saving slightly stale data beats dropping this run's probe results").

the corresponding test (`"falls back to saving its own snapshot clone when the reload fails"`) confirms this gap: it uses `mockRejectedValue(new Error("EBUSY"))`, which exercises the dead catch, but the production `loadQuotaCache` would resolve instead of reject. the passing test gives false safety on a code path that is never reached.

### Issue 2 of 3
test/codex-manager-login-menu-refresh.test.ts:107-121
**test exercises dead catch branch**

`loadQuotaCacheMock.mockRejectedValue(new Error("EBUSY"))` is the only way to reach the catch in the rebase block, but the real `loadQuotaCache` in `lib/quota-cache.ts` never rejects — it catches internally and returns `{}`. this test passes but verifies a code path that never fires in production, so the actual EBUSY behavior (silent empty-object reload → partial save) has no coverage.

### Issue 3 of 3
lib/codex-manager/login-flow.ts:95-101
**no test pins the drain-before-exit contract**

the three `drainPendingMenuQuotaRefresh` call-sites cover the stated exit paths, but no vitest case asserts that a drain actually happens before `persistAccountPool` is reached. the `codex-manager-cli.test.ts` changes verify refresh settling within a menu pass, which is a different assertion. a test that starts a slow in-flight refresh and verifies `persistAccountPool` is only called after the drain resolves would lock in the windows EBUSY fix and prevent regression on this path.

_{Reviews (1): Last reviewed commit: "fix(codex-manager): close the menu quota..." | Re-trigger Greptile}

Greptile also left 3 inline comments on this PR.