fix(antigravity): read sidecar-less WAL conversations with an immutable fallback - #3532
fix(antigravity): read sidecar-less WAL conversations with an immutable fallback#3532urda wants to merge 2 commits into
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
|
Codex review: needs maintainer review before merge. Reviewed September 10, 2026, 11:18 AM ET / 15:18 UTC (Revision 5). ClawSweeper reviewWhat this changesAdds a guarded SQLite fallback for Antigravity conversation databases without WAL sidecars, with regression coverage, documentation, and a separate billing-test timing adjustment. Merge readiness✅ Ready for maintainer review This remains a useful fix: current main and v0.58.0 lack the fallback. The earlier review findings are addressed, the reported macOS run demonstrates restored history, and no blocking introduced defect was found. Priority: P2 Review scores
Verification
How this fits togetherCodexBar reads Antigravity conversation databases to build local token history for its CLI and usage displays. Incomplete database scans prevent that history from being published as established usage. flowchart TD
A[Local conversation databases] --> B[Ordinary read-only SQLite scan]
B --> C{Cannot open and no WAL file?}
C -->|Yes| D[Immutable read with stability checks]
C -->|No| E[Existing scan result]
D --> E
E --> F{Complete history?}
F -->|Yes| G[Publish daily token history]
F -->|No| H[Withhold incomplete history]
Before mergeNone. Agent review detailsSecurityNone. Review metrics
Technical reviewBest possible solution: Restore stable, closed-conversation history through the bounded fallback while retaining normal WAL coordination and withholding scans whose stability cannot be established. Do we have a high-confidence way to reproduce the issue? Yes: the reported Apple SQLite failure maps directly to main's incomplete-scan path, and the sidecar-less WAL fixture exercises that platform condition. This review did not execute tests or a live account probe. Is this the best way to solve the issue? Yes: the retry stays within the existing reader, preserves its budgets and publication checks, and follows an established repository pattern with an additional stability guard. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against 7fdc17636f16. LabelsLabel justifications:
EvidenceWhat I checked:
Likely related people:
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (4 earlier review cycles)
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 895a9ba145
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
@codex review |
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. |
|
Codex Review: Didn't find any major issues. 🚀 Reviewed commit: ℹ️ About Codex in GitHubCodex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback". |
…immutable fallback
476c332 to
3ea3844
Compare
Summary
One cleanly closed Antigravity conversation makes the whole Antigravity spend history unavailable on macOS. The Usage & Spend pane then lists no Antigravity source and shows "Refresh failures: 1", and
codexbar cost --provider antigravityreturns an empty report withhistoryCoverageIsEstablished: false.The cause is a SQLite platform behavior. When SQLite closes the last connection to a WAL database cleanly, it deletes the
-waland-shmsidecars. Apple's system SQLite (3.51.0 on macOS 26) then declines a read-only open of that file withSQLITE_CANTOPEN, because a read-only connection may not create the sidecars. The reader marks that database incomplete, the report becomes partial, and the fetcher withholds every row by design.This PR adds a narrow fallback in
AntigravityLocalReader.readDatabase:SQLITE_CANTOPENbefore any row is read, and no-walsidecar exists next to the database, the reader retries that one database withfile:<path>?immutable=1andSQLITE_OPEN_READONLY | SQLITE_OPEN_URI.-walmeans no WAL connection holds the database, so the main file alone carries the checkpointed state. A database with a-walsidecar present stays unavailable, as before.%,?, and#cannot change the URI.Statistics.immutableFallbackscounts the retries.The
#3212WAL test carried the comment "Some SQLite builds decline read-only WAL access without sidecars; that must stay unavailable." This PR argues against that ruling with field data: every new conversation lacks sidecars until some later bulk event recreates them, so the current policy blanks Antigravity spend for most macOS users most of the time.Evidence
On the reporting machine, 214 conversation databases exist. 213 have sidecars and open read-only. One has a WAL header (
writer version 2, read version 2) and no sidecars, and it fails:A one-off Swift probe that links the system SQLite3 library reproduces
rc=14at prepare after a successful open andBEGIN DEFERRED. Python's bundled SQLite 3.53.4 opens the same file and creates the sidecars. Sidecar birth times on the 213 databases cluster on five moments (184 of them on one day), not on each conversation's creation, so new conversations regularly lack sidecars.With this change, the same CLI command on the same machine returns 38 daily rows from 2026-06-20 through 2026-09-06 with
historyCoverageIsEstablished: true, and the file still has no sidecars afterwards.Trade-off
An immutable connection skips locking and change detection, so the read alone cannot prove one snapshot. The stability bracket above turns that into a fail-closed check: any change to the main file or the appearance of a
-walsidecar during the retry marks the database incomplete. The next scan reads the stable file. A temp copy would carry the same window and cost I/O on every refresh.Tests
All three cases keep the existing raw-SQLite control pattern: a separate control fixture reports which outcome the platform's SQLite produced, and the expectations follow that outcome. On Apple's SQLite the control returns
SQLITE_CANTOPENand the fallback path runs; on a SQLite that creates the sidecars itself, the ordinary path runs and no fallback is counted.AntigravityLocalWALTests: the existing sidecar-less case now expects.completecoverage and the fixture row on every platform,immutableFallbacksequal to 1 only when the control declined, and no sidecars afterwards in that case.%,?, and#reads completely through the escaped URI.-walsidecar never takes the fallback. Apple's SQLite declines that open, so the guard is exercised on macOS and the report stays partial. A root CI user can still read the file, and the control accepts that outcome.Commands run
Docs
docs/antigravity.mddescribes the fallback and its guard under "Local token history". No CHANGELOG entry, per repository convention.