fix(antigravity): skip steps without stepUUID during token scan - #3451
fix(antigravity): skip steps without stepUUID during token scan#3451horosin wants to merge 3 commits into
Conversation
Skip auxiliary and lifecycle steps lacking a stepUUID in the steps table rather than invalidating the entire database scan. Antigravity logs non-conversational steps (e.g., lifecycle markers, auxiliary status transitions) in its SQLite steps table that omit field 12 (stepUUID). Previously, encountering any row lacking a stepUUID flagged rowsAreValid = false, which cascaded to make the entire multi-database token scan incomplete and completely withheld local token history. Generation rows requiring step timestamps remain protected by checking recoveredCount against pendingTimestampRows.count. Added regression tests verifying that rows without stepUUID are safely skipped while preserving full coverage.
|
🦞👀 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. |
clawsweeper
Bot
added
P2
|
Codex review: needs maintainer review before merge. Reviewed September 6, 2026, 4:36 PM ET / 20:36 UTC. ClawSweeper reviewWhat this changesSkip Antigravity auxiliary SQLite steps without a step UUID while preserving conflicting bot-ID evidence, with regression tests and documentation updates. Merge readiness✅ Ready for maintainer review This remains a useful, focused fix: current main and v0.56.7 still reject UUID-less steps. The earlier bot-ID conflict finding is resolved, the supplied CLI proof demonstrates restored history, and no new blocking defect was found. Priority: P2 Review scores
Verification
How this fits togetherCodexBar reads Antigravity’s local conversation databases and recovers timestamps for token usage. Scan completeness determines whether the CLI and app can display token history. flowchart TD
A[Local conversation databases] --> B[Read generation usage]
B --> C[Recover missing timestamps from steps]
C --> D[Preserve conflicting identity evidence]
D --> E[Skip UUID-less auxiliary steps]
E --> F{History complete?}
F -->|Yes| G[Display token totals]
F -->|No| H[Withhold incomplete history]
Before mergeNone. Agent review detailsSecurityNone. Review metrics
Technical reviewBest possible solution: Retain the narrow auxiliary-row tolerance while continuing to withhold unresolved generations and contradictory timestamp evidence. Do we have a high-confidence way to reproduce the issue? Yes: current main rejects a valid UUID-less step whenever generation timestamps require the steps scan, propagating incomplete coverage. The contributor supplies before/after CLI output; this review did not execute a reproduction. Is this the best way to solve the issue? Yes: the patch adjusts the auxiliary-row guard within the existing reader and preserves ambiguity handling, avoiding a parallel parser or fallback path. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against 7353c717502d. LabelsLabel justifications:
EvidenceWhat I checked:
Likely related people:
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (3 earlier review cycles)
|
Record botID ambiguity before skipping steps that lack a stepUUID. If an auxiliary step row carries a botID but lacks a stepUUID or timestamp, record it as ambiguous so it cannot later be used as exact timestamp evidence. Add regression tests validating that UUID-less step rows with duplicate botIDs invalidate exact evidence in either row order.
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. |
clawsweeper
Bot
added
proof: sufficient
steipete
left a comment
steipete
left a comment
There was a problem hiding this comment.
The bot-ID ordering fix addresses the earlier finding, and the rebuilt CLI output is useful availability proof. One date-attribution boundary still needs to be established before landing this skip.
parseStepMetadata does not identify a lifecycle step type. The new guard skips every syntactically valid record without a UUID, including the unknown-field-only record in the existing regression. With two pending generations sharing a UUID, one identified step timestamp, and one unidentified occurrence, skipping the latter leaves the single-timestamp fallback free to assign the identified timestamp to both generations. recoveredCount still reaches the expected count, so it does not prove that attribution was valid. The changed regression now explicitly accepts that case.
Please restrict the skip to positively identified auxiliary records while preserving unidentified occurrence evidence, or provide a producer contract establishing that UUID-less records cannot represent relevant generation occurrences. Keep coverage for unknown-field-only and timestamp-bearing unidentified records alongside the harmless lifecycle fixture. Restored total token counts alone do not verify the dates assigned to those generations.
Reviewed head: e305c32673e9ef74d42c72e4dcc631778070676f. This is a source/test-contract concern; I am not claiming to have inspected the private history used in the CLI demonstration.
…#3462) Antigravity bookkeeping rows without a step UUID caused the entire local history provider to be withheld as incomplete. Permit those rows after charging their row and byte budgets, while keeping malformed data and exhausted budgets as hard failures. A lone identified timestamp cannot stand for every occurrence of a reused UUID when unidentified rows are present. Rows without UUIDs can still carry bot identity. Record that evidence before skipping UUID positioning: a duplicate bot ID with unknown UUID permanently invalidates exact and positional matches, regardless of scan order, matching timestamps, or absent timestamps. This addresses the review finding on the original revision. Keep ambiguous positional slots intact so later timestamps never move into them. Share the identical step-occurrence structs, remove an unused counts projection, and apply positional ambiguity during timestamp selection. The final PR reduces production code by four lines. Token counts, pricing, credentials, discovery roots, and stored data remain unchanged. Changelog and documentation are updated; thanks @urda. Maintainer validation: six synthetic duplicate-bot combinations failed 18 assertions on the original PR and pass after repair. All 406 focused Antigravity tests across 34 suites pass, including harmless bookkeeping, reused UUIDs, embedded timestamps, malformed rows, and budgets. `make check` passes and independent review is clean. The full `make test` suite passed all 1,028 selections across 86 groups without retries. The main integration preserves the tested Antigravity source, tests, and documentation byte-for-byte; integration `make check` also passes. Exact-head CI must pass before merge. Contributor live evidence, collected on the original proposal: @urda compared the shipped 0.56.6 CLI and a rebuilt CLI against the same 211 stable local session databases from agy 1.1.27, using read-only scratch copies with WAL sidecars. Complete coverage increased from 208 to 211; the three recovered sessions contained 80,067, 48,183, and 5,299,395 tokens. Removing UUID-less bookkeeping rows from copies also made the shipped CLI return complete coverage, isolating the original cause. One previously passing session's output, excluding updatedAt, matched byte-for-byte. Three actively written sessions were excluded because both binaries reported them incomplete until checkpointing. This is contributor-reported live evidence; the maintainer's final ambiguity repair uses synthetic native SQLite fixtures. This builds on #3266, #3396, and #3403. It is distinct from #3412's cost-estimation changes. Earlier proposal #3451 remains related; no unrelated issue is claimed resolved. Co-authored-by: Peter Urda <peter.urda@gmail.com>
|
Thanks @horosin for identifying this and providing the live CLI trace. The reported UUID-less bookkeeping-row failure and bot-ID ambiguity handling are now addressed on main by #3462 (a1391fc). The landed fix also retains ambiguous positional slots and withholds shared timestamps for reused UUIDs when unidentified rows leave the evidence incomplete. It passed 406 focused Antigravity tests, the full suite, and CI. I compared this PR's final diff with that implementation; closing this overlapping proposal in favor of the landed fix. |
|
Thank you @steipete! Really appreciate active maintaining of the project |
2 participants
Summary
I've been wanting to see Antigravity usage and cost tracking in CodexBar work just like Codex does. I saw the recent improvements in #3403 to fix token counts and the ongoing work in #3412 to pull dollar amounts. However, on my machine, local Antigravity token counts were still not showing up at all, withholding with:
In anticipation of full Antigravity cost support landing, I dug into why token history was still withheld and found a false-positive check during SQLite step scanning that this PR fixes.
Problem
In
readStepTimestamps(Sources/CodexBarCore/Providers/Antigravity/AntigravityLocalSQLite.swift), encountering a row in thestepstable without astepUUIDsetrowsAreValid = false.Antigravity legitimately logs non-conversational steps in its SQLite
stepstable (such as internal lifecycle markers, model config transitions, or auxiliary events). These records have timestamp fields (field 1) and step types (field 3), but omit field 12 (stepUUID) because they are not LLM turns.When
readStepTimestampsencounters any such step row without astepUUID:rowsAreValid = false.stepScan.isCompleteevaluates tofalse.isComplete = false.result.isCompleteacross all historical databases is an aggregate booleanAND, a single auxiliary step in any conversation database cascades to invalidate all databases across the entire machine, completely withholding token history.Solution
stepstable rows without astepUUIDinstead of invalidating the entire database scan.gen_metadatathat actually depend on external step timestamps remain fully protected by the existingrecoveredCount < rows.pendingTimestampRows.countcheck.botIDambiguity before skipping UUID-less rows: if an auxiliary step row carries abotIDbut lacks astepUUIDor timestamp, it is recorded as ambiguous so it cannot be mistakenly used as exact timestamp evidence.[0x0A, 0x0C, 0x08, 0xA7, 0x8C, 0xE6, 0xD4, 0x06, 0x10, 0xC0, 0xD5, 0xA0, 0xCB, 0x03, 0x18, 0x05, 0xD2, 0x01, 0x00]), and tests for duplicate bot IDs on UUID-less rows in either row order.docs/antigravity.mdandCHANGELOG.md.Real Behavior Proof
Before Fix
Token history was withheld across the entire machine with coverage marked incomplete:
After Fix
Local SQLite scan recovers full token history across all conversations:
Validation
All 403 Antigravity-focused tests and
make check(SwiftFormat, SwiftLint, Oxlint) pass cleanly.