fix: resolve Antigravity quotas independently per cadence - #3220
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. |
|
Codex review: needs maintainer review before merge. Reviewed August 26, 2026, 7:55 PM ET / 23:55 UTC. ClawSweeper reviewWhat this changesThe PR makes Antigravity Session and Weekly menu-bar values independently select the most constrained known quota-summary row across model families. Regression provenancePossible regression — probable (reproduction; reviewed change). No predecessor PR is attributed. Merge readinessKeep open for owner review and merge: the focused fix is source-backed, has direct render proof, and has no actionable defect; exact-head macOS checks are still running. Priority: P2 Review scores
Verification
Live VerificationCommand: Result: FAIL (failed) — execution before step 1 Assertions:
How this fits togetherCodexBar parses provider quota responses into a usage snapshot, then resolves semantic Session and Weekly values before rendering the menu-bar label. Antigravity has two model families whose representative rows can describe different cadences. flowchart LR
A[Quota response] --> B[Usage snapshot]
B --> C[Antigravity summary rows]
C --> D[Cadence resolver]
D --> E[Session value]
D --> F[Weekly value]
E --> G[Menu-bar label]
F --> G
Before merge
Agent review detailsSecurityNone. Review metrics
Root-cause clusterRelationship: Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Land this provider-specific semantic resolver after the exact-head macOS shards complete successfully, preserving the existing automatic and explicit metric policies. Do we have a high-confidence way to reproduce the issue? Yes—current source and the supplied parsed quota fixture establish the affected resolver path, although this read-only review did not execute it. Is this the best way to solve the issue? Yes—the provider-specific semantic resolver is the narrowest maintainable repair because Antigravity family representatives can correspond to different cadences. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against abe8f9180a75. LabelsLabel changes:
Label justifications:
EvidenceWhat I checked:
Likely related people:
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (1 earlier review cycle)
|
|
Merged as 6e99898b7c9e; #3206 is closed. Local main fast-forwarded and is clean. The fix is provider-owned: Antigravity now chooses the most constrained known quota independently for each semantic cadence. The actual family representatives remain untouched, and the shared fallback only gains an availability filter. Automatic selection, exhausted-quota preference, explicit family metrics, diagnostic rows, authentication and refresh behavior are unchanged. Verification:
This is source, regression and offscreen production-render proof, not live provider or status-button placement/refresh proof. No real account, saved credentials, app-bundle launch, or persisted settings/account change was used. Final exact-head CI passed lint, Linux x64/ARM builds/tests/smoke checks, musl, both macOS shards, provider-engine goldens, and the aggregate at |
Summary
Fixes #3206.
Antigravity's Gemini and Claude/GPT representatives can describe different cadences. With Gemini at 86% session / 55% weekly remaining and Claude/GPT untouched, the old semantic resolver selected the untouched family's session and displayed
5h 100% · W 55%.Resolve Session and Weekly independently from the provider's known quota-summary rows, reusing its existing most-constrained helper. Preserve unavailable/missing cadences when summary rows exist and standard fallback when they do not. The shared fallback now ignores explicitly unknown extra rows without changing its representative-first/first-match policy for other providers.
Automatic selection, exhausted-quota preference, explicit family metrics, icon selection, raw snapshots and diagnostic rows are unchanged. Provider docs and changelog updated; thanks @foobra for the report.
Before / after
Identical parsed synthetic fixture and identical opt-in harness, run before any production edit and after the fix. Both use the production semantic resolver, title renderer and preview view. No account data is present.
Before:
After:
This is offscreen production-render proof, not a live provider or desktop status-item capture. It verifies parsing-to-selection-to-rendered text and accessibility, not fetching, status-button assignment, placement or refresh propagation. The harness creates no controller, status bar, settings store, real window or account fixture, and skips before fixture creation unless explicitly enabled.
Verification
swift test --filter 'AntigravityQuotaSummaryTests|MenuBarLayoutTests.*semantic|MenuBarMetricWindowResolverTests|MenuCardAntigravityTests|ProviderPresentationPolicyCharacterizationTests|UserPluginQuotaPresentationTests' --skip 'MenuBarLayoutTests.*Kimi lane overrides'with test Keychain access suppressed/disabled and the allow override unset. The skip excludes an unrelated migration fixture accidentally matched by the broad name filter; the full suite runs without that exclusion.swift test --filter MenuLayoutScreenshotRenderTests/test_renderAntigravitySemanticLayoutProofpassed withCODEXBAR_ANTIGRAVITY_LAYOUT_SCREENSHOT_DIRset separately for before and after. The opt-out invocation skipped cleanly. Both PNGs were inspected before upload.make checkandgit diff --checkpassed; generated provider/plugin artifacts remain current.make checkalso passed with zero violations.env -u CODEXBAR_ALLOW_TEST_KEYCHAIN_ACCESS CODEXBAR_SUPPRESS_TEST_KEYCHAIN_ACCESS=1 make testpassed all 933 selections in 78 groups: every group first-pass, zero failures/retries/timeouts, 878.3 seconds. No focused-test exclusion was used.ba732e417c03b9e48856e7ac5f829664c2dc8baepassed: lint, Linux x64/ARM builds/tests/smoke checks, musl build, both macOS shards, provider-engine goldens, and aggregate. No CI rerun was needed.No real credentials, provider requests, app-bundle launch or persisted account/config changes were used.