Fix the Antigravity reset time and make its failures diagnosable - #451
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe Antigravity provider now parses quota reset timestamps, preserves malformed values, and reports sanitized diagnostics for failed or unusable status and quota-summary responses. ChangesAntigravity status and quota handling
Priority: ⬇️ Low Estimated code review effort: 3 (Moderate) | ~20 minutes Change: Bug fix Suggested reviewers: Merge Risk: ⚪ Minimal · up to The reset parsing and sanitized diagnostic changes have no identified actionable risk, so the change is ready to merge. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
ceiling | 897d86c | Commit Preview URL Branch Preview URL |
Sep 18 2026, 02:11 AM |
Two fixes from #412.
The reset time
The language server sends the reset as an RFC 3339 timestamp, and
rate_window_from_remaininghanded it toRateWindow::with_detailsas the description, leavingresets_atempty. Every surface formatsresets_atand falls back to the description only when it is missing, which is why the panel printed the raw2026-09-16T22:33:14Z. It now parses intoresets_at, so both the countdown and the local-time rendering work. A value in an unexpected shape still falls back to being shown as text, exactly as before.Diagnosability
His diagnostic says "The provider returned an unexpected error." and that was all it could say:
GetUserStatusdropped its error with.ok(),RetrieveUserQuotaSummarywithif let Ok(..), and the diagnostic replacesProviderError::Otherwith a generic string by design. A signed-out language server, a changed response shape and a timeout were all indistinguishable.The response bodies the API errors carry are never repeated outside the debug log.
Verification
cargo test --manifest-path rust/Cargo.toml antigravity, with 4 new tests: the timestamp lands inresets_atwith no description, an unparseable reset time still shows as text, a failure reason carries the status but not the body, and the message names whichever of the two calls failed.cargo fmt --all --checkclean.cargo clippy --manifest-path rust/Cargo.toml --all-targets -- -D warningsclean.Note
Fix Antigravity reset timestamp parsing and add safe failure diagnostics
resets_atas a UTCDateTimeinstead of being stored as description text; unparseable values remain in the reset description as a fallbackGetUserStatusandRetrieveUserQuotaSummaryfailures now record whether the response was empty or failed, and the combined provider error names which request failed with a safe HTTP status or failure category (response bodies are excluded)short_reasonanddescribe_unusablehelpers in mod.rs to build the compact failure messagesrate_window_from_remainingnow returns aDateTime<Utc>for valid timestamps instead of a string; callers that relied on the reset value appearing in the description will no longer see it there when parsing succeedsMacroscope summarized 897d86c.
Summary by CodeRabbit