fix(antigravity): recover step timestamps via exact bot ID join - #3403
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9f114a9171
ℹ️ 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: blocked before merge. Reviewed September 3, 2026, 2:43 PM ET / 18:43 UTC. ClawSweeper reviewWhat this changesThe PR uses validated Antigravity per-turn bot IDs to recover missing local-history timestamps without misdating reordered or conflicting step records. Merge readiness⛔ Blocked before merge - 1 item remains Keep open: the rebased PR has a focused, fail-closed implementation with extensive regression coverage and credible production-CLI proof; no introduced correctness defect was found. Priority: P2 Review scores
Verification
How this fits togetherCodexBar reads Antigravity’s local SQLite history, decodes generation and step metadata, and aggregates valid events into daily token-usage reports. Those reports feed the CLI, dashboard, and cost displays. flowchart LR
A[Local SQLite history] --> B[Generation rows]
B --> C{Timestamp present?}
C -->|No| D[Step metadata scan]
D --> E[Validated turn ID join]
C -->|Yes| F[Daily usage report]
E --> F
F --> G[CLI and dashboard]
Before merge
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Merge the validated fail-closed recovery once the exact-head macOS checks complete, retaining partial coverage for ambiguous producer data. Do we have a high-confidence way to reproduce the issue? Yes. The PR supplies a concrete actual-CLI synthetic SQLite before/after scenario, and focused tests encode reordered, duplicate, malformed, and fallback cases; this read-only review did not rerun it. Is this the best way to solve the issue? Yes. Validating a unique same-UUID bot-ID join while preserving the existing positional fallback is narrower and safer than inferring dates from unrelated metadata. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 7e9c1e8a54af. LabelsLabel changes:
Label justifications:
EvidenceWhat I checked:
Likely related people:
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
History |
Recover standard step timestamps using validated per-turn identities without shifting auxiliary steps into generation slots. Preserve legacy fallback, embedded timestamps, optional-ID tolerance, and copied-row accounting; withhold contradictory evidence. Co-authored-by: WeGoToMars <profigor7@gmail.com>
9f114a9 to
bda9352
Compare
|
Repaired the existing branch at bda9352 and rebased it onto current main, retaining @WeGoToMars's contribution. Both outstanding inline findings are now fixed: generation-side identity counts include embedded and UUID-less rows, and malformed auxiliary IDs stay invalid across repeated fields/envelopes. Regression tests reproduced both failures before the fix. The revision also preserves ambiguous positional slots, rejects missing-time and cross-UUID conflicts, checks embedded exact-ID agreement without blocking unrelated UUIDs, and keeps optional parser state out of copied-row equality. The shipped 0.56.4 CLI reproduced the wrong-day assignment on a synthetic SQLite fixture. The rebuilt CLI assigns the same 198 tokens to the correct day, withholds conflicting evidence, and preserves legacy no-ID history. No private history or accounts were used, and the final CLI run left the fixture databases unchanged. The PR body has the proof matrix and scope limitations. All 401 Antigravity-focused tests, lint, and the required autoreview have passed. The final full suite is running; the reviewed-head CI run has been approved. I will wait for both before merging. |
|
Merged as 0b181cc. The clean main checkout has the same file tree as reviewed/tested head bda9352. Thanks @WeGoToMars! Final verification:
The actual shipped and rebuilt CLIs were exercised with Unknown or contradictory metadata intentionally remains partial coverage instead of acquiring a guessed date. This does not validate opaque relative-clock fields or fix unrelated Antigravity quota/auth reports. The docs and Unreleased changelog record that boundary. |
Summary
Fix Antigravity local token history being assigned to the wrong timestamp when auxiliary or reordered step rows share a generation's step UUID. The previous reader accepts an ordered step prefix; a count mismatch alone does not necessarily make it withhold history.
Use the generation usage
bot_idand the matching step metadatabot_idto recover the standard seconds/nanos timestamp within the same UUID. This does not interpret opaque context-meter fields, use session creation time, or change token counts, pricing, credentials, discovery roots, or stored data.The maintainer revision retains the contributor's exact-ID approach and strengthens its safety boundaries:
Proof
Ran the shipped 0.56.4 CLI and the rebuilt CLI against three synthetic SQLite histories, with a temporary home, account-file/Keychain test isolation, network denied, and real home-directory reads denied. No real accounts or history were used.
The final CLI run left all three input database hashes unchanged. Assertions cover input, cache-read, output, and reasoning buckets as well as dates and coverage.
Focused regression tests first failed on the contributor proposal, including embedded-ID uniqueness, malformed repeated IDs, positional compression, cross-UUID fallback, and missing-time duplicates. Additional tests caught and repaired over-withholding of repeated generation IDs and false copied-row conflicts.
swift test --filter Antigravity: 401 tests across 34 suites passed (383 macOS tests and 18 portable tests).make check: passed, zero violations in 2,098 files. A local Homebrew Bash here-document stall was isolated to a temporary system-Bash command path; no repository toolchain change.make test: all 1,002 selections across 84 groups passed first try in 861.9 seconds, with zero failures, timeouts, or retries.The original author's live-data observations are useful schema evidence but were not independently replayed against private history. This revision's executable proof is synthetic and uses the actual CLI entry point.