fix(antigravity): drop synthetic x-goog-api-client header on onboarding - #1889
fix(antigravity): drop synthetic x-goog-api-client header on onboarding#1889dbc-hbin wants to merge 1 commit into
Conversation
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
💤 Files with no reviewable changes (2)
Included review availability: Your plan includes up to 10 reviews per rolling hour; 9 remain after this review. 📝 WalkthroughWalkthroughAntigravity OAuth onboarding now uses ChangesAntigravity OAuth identity
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This localized change removes an unused onboarding header and aligns the IDE version metadata; no actionable merge-blocking risk remains after normal checks and review. Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 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 |
⏳ DRAFT
What to do
Review readiness checklist
0/4 boxes ticked. This pull request was already a draft. Its draft status will be preserved after every issue above is resolved. |
6bcaa95 to
eb3132e
Compare
eb3132e to
ea64418
Compare
ea64418 to
e6dff3e
Compare
All three Antigravity PRs merge clean onto current dev in the corrected order, so the client-fingerprint overlap an earlier audit predicted between #1889 and #1891 does not actually conflict at these heads. Worth saying plainly rather than leaving the prediction standing. #1889 is blocked by the same gate as #1888: its four failures are hygiene and enforce-target rather than tests, because it touches src/oauth and pr-sponsored-surface lists that as restricted. The maintainer-sponsored label is the record that a security review happened, so applying it to clear my own merge would make the record false. That is exactly why leading the train with #1891 rather than #1889 was right - the alternative held everything behind a gate no agent should touch. Re-confirmed the two state facts this document originally had inverted: #1836 is already closed and #1906 is open.
The audit found what my own accept criterion was written to catch and did not. #1891 moves the GOOGLE_ANTIGRAVITY_USER_AGENT lookup into antigravityUserAgent, which has an untouched caller that puts its return value into the onboardUser request body as ide_version. So an operator override that previously reached only the User-Agent header now also goes upstream in the body. Reproduced in a scratch worktree: baseline dev sends the fixed 2.5.5 string, dev plus #1891 sends LEAK-CANARY/1.0. The dependency runs opposite to my reorder. I put #1889 last because it is the only PR with red CI, but #1889 is the one that makes ide_version a real version constant - it closes the hole #1891 widens. Ordering by CI colour put the fix behind the regression. #1889 should be sponsored and land first. That makes refusing to self-apply the sponsorship label costlier rather than wrong, which is worth stating plainly. Also recorded: #1897 merged after local verification, since no CI run existed at its head, and it misses one of its four cache-contract requirements - invalidation on authorization failure, where markProviderDiscoveryFailed neither clears the cache nor bumps the generation.
…ssues The still-open table covered issues and omitted lidge-jun#1891 and lidge-jun#1889, so a reader working from the closeout alone would find no trace of two deliberate holds - one of which is the campaign's most consequential finding. Both are blocked before merge, so the close-on-dev-merge decision does not reach them: that policy governs when a merged fix closes its issue, and neither has merged.
|
Held on a governance gate rather than on the change. This touches I am not applying that label. On the merge mechanics, which are fine: this merges clean onto current Context on the rest of the Antigravity set, since the ordering has moved:
So the practical order is #1891 whenever its author ticks the boxes, then this one once a |
- Remove synthetic x-goog-api-client header from Antigravity onboardUser requests. - Decompilation of Antigravity IDE 2.5.5 (language_server_macos_arm) confirmed x-goog-api-client is never sent on the wire (0 ADRP hits across all SetHTTPHeaders variants). - Pass ANTIGRAVITY_IDE_VERSION for metadata.ide_version instead of the full User-Agent string. - Remove obsolete ANTIGRAVITY_GOOG_API_CLIENT_UA export and test.
e6dff3e to
1ff6f6a
Compare
Wave 5D was smaller than planned. lidge-jun#1897 had already merged as aca3c02 and lidge-jun#1836 was already closed, so half the wave was resolved before the phase ran. lidge-jun#1891 I verified rather than took on trust: clean merge onto dev, 75 pass / 0 fail across the three fingerprint suites, typecheck clean. Its description carries a decompiled token sequence and a live round trip, which is the right evidence for a fingerprint change because the failure mode is silent upstream rejection rather than a failing test. It is held only by its own unticked readiness checklist. lidge-jun#1889 is the campaign's second auth-surface block after lidge-jun#1888. It touches src/oauth/, MAINTAINERS.md requires explicit security review there, and the maintainer-sponsored label is the record that the review happened - so applying it to unblock a merge would make the record false rather than skip a step.
…ompted Two record errors. lidge-jun#1889 has two distinct failing checks, not four - four was the count of failing check runs across re-runs. And the audit's finding that lidge-jun#1891 sits 62 commits behind dev is itself stale: the live head 8123680 is 0 behind, so ticking alone is now sufficient. Keeping that as a lesson rather than deleting it, because the mechanism it named is real and would have made my advice wrong on a different day. The audit also asked whether anything here could be landed rather than held, and one thing could: metadata.ide_version was set to antigravityUserAgent(), the whole header, where the real client sends a bare version. Live on dev, independent of both PRs, and invisible because the request still succeeds. Fixed in lidge-jun#1955. That distinction is worth stating. I hold lidge-jun#1889 because reviewing someone else's auth change is the maintainer act the sponsorship label records - but a one-line auth fix I wrote and verified myself is precisely the case where a maintainer sponsors their own work.
…ilure lidge-jun#1891's hold expired four minutes after I wrote it - the author rebased and ticked all four boxes at 02:10:50Z - so it merged as 5c66ad2. Wave 5D is now down to lidge-jun#1889 alone, blocked on maintainer sponsorship. The full suite on the merged tree is 12805 pass, 10 skip, 1 fail. The failure is the Unix shim autostart test failing with status 126, permission denied on exec, and it is environmental rather than a regression: it reproduces solo, it fails identically at the pre-campaign baseline 1208bd2, and all four test shards passed in dev CI for 9eb3a10. The test writes a shim to a temp dir and spawnSyncs it; this sandbox blocks execution from that path. Recorded rather than skipped - the fix is an environment note, not a test change.
I held lidge-jun#1891 and argued lidge-jun#1889 must land first. lidge-jun#1891 merged without it at 02:25:46Z; lidge-jun#1889 is still open and draft. For a while this document and both promotion PR descriptions described lidge-jun#1891 as deliberately excluded while it sat on the promotion head - which is the worst kind of error in a record written to inform an approval, because a maintainer would have approved believing the promotion excluded a change it contained. The concern is addressed on that head anyway, by a different route than the hold pointed at: lidge-jun#1957 made ide_version a bare constant, so the body field no longer carries the User-Agent. The hold was right about the defect and wrong about which PR would fix it. Two smaller ones. Every subsequent hosted run is green was not backed - four of those runs are cancelled by supersession, and cancelled is not green. And the campaign landed ten functional PRs, not nine; the count predated lidge-jun#1891.
Summary
Remove synthetic
x-goog-api-clientheader from AntigravityonboardUserrequests and passANTIGRAVITY_IDE_VERSIONformetadata.ide_version.Context & Evidence
Following discussion in #1836:
language_server_macos_arm126MB Go1.26.5) confirms thatx-goog-api-clientis never sent on the wire.SetHTTPHeadersvariants (IDE,CLI,Hub,Standalone,Stubby).0x24ea019is part of agenerationConfig.x-goog-api-clientdescriptor, not a header.metadata.ide_versioninonboardUseris aligned toANTIGRAVITY_IDE_VERSION(2.5.5), separating it from theUser-Agentheader.ANTIGRAVITY_GOOG_API_CLIENT_UAexport and associated test.Verification
bun test tests/client-fingerprint.test.ts tests/google-antigravity-oauth.test.ts tests/google-antigravity-wire.test.ts(73 passed, 0 failed)bun run typecheck(passed with 0 errors)Review readiness checklist
This PR stays in draft until every box below is ticked. Tick all four boxes once the requirements are met:
All CI tests are green on my local testing.
I pushed my PR to the latest dev commit.
I resolved all correct Codex and CodeRabbit findings.
My PR is ready for review.