[Bug]: Antigravity quota refresh failure — investigate missing canonical Fake-IP handling

[jaychou0642-create]

Canonical quota transport landed; field acceptance remains open

#3799 (f7bc920051) supplies fixed-destination canonical proof and aligns Antigravity quota fallback transport. Authenticated TUN/Fake-IP observation and safe user-facing failure categorization remain outstanding; this is not a claim that the reporter's full scenario was verified.

Verified against dev 5759d9ea2f1e7281cdc01eb9628f2e0a123fb59c. Original report by @jaychou0642-create. The attribution record was added in #3811.

Problem

The Google Antigravity Accounts page can display “额度刷新失败” (Quota refresh failed) and “速率限制数据暂时不可用” (Rate-limit data temporarily unavailable) after clicking Refresh quota.

Code-level investigation

In the 2.43.0 implementation, fetchAntigravityUsageQuota() in src/providers/quota.ts calls providerOutboundPost() for the fixed Google retrieveUserQuotaSummary and fetchAvailableModels URLs. Its outbound dependencies default to an empty object.

In src/lib/provider-outbound.ts, the transparent Fake-IP exception requires an isCanonicalUrl proof when there is no explicit outbound proxy. Model discovery supplies such a proof, but the quota path appears not to.

This suggests a compatibility gap worth testing: quota probes may reject Fake-IP DNS answers even where model discovery supports transparent proxying. This is a hypothesis from source inspection, not a confirmed end-to-end root cause.

Expected behavior

• Test quota probing with Fake-IP DNS and no explicit HTTP proxy.
• If needed, provide a narrowly scoped canonical-destination proof for the fixed Google quota URLs.
• Preserve TLS verification, redirect restrictions, and rejection of unrelated private or metadata destinations.
• Surface a safe error category for failed quota probes instead of only the generic unavailable message.

No authenticated upstream response or verified workaround is included in this report.

[lidge-jun]

리뷰 · 우선순위 68 / 80

이 이슈는 Google Antigravity 계정 화면에서 “쿼타 새로고침”을 눌렀을 때 “额度刷新失败 / 速率限制数据暂时不可用”이 뜨는 현상을, Clash·Surge·Mihomo 같은 TUN Fake-IP DNS(198.18.0.0/15) 환경과 맞춰 조사해 달라는 보고입니다. 리포터도 말했듯이 지금 단계는 인증된 업스트림 응답으로 확정한 재현이 아니라, HEAD 소스 대조로 나온 호환 구멍 가설입니다. 그래도 가설이 가리키는 코드 경로는 지금 dev HEAD bd1cda99c(package 2.44.0, #3768 credential 선택 공유까지 들어간 release-244)에서도 그대로 열려 있습니다.

핵심은 outbound 정책의 Fake-IP 예외가 “증명 없으면 닫힘”이라는 점입니다. src/lib/provider-outbound.ts의 ProviderOutboundDependencies.isCanonicalUrl은 기본값이 “항상 false”이고, 투명 Fake-IP 예외(transparentFakeIpException)는 이 증명이 참일 때만 198.18 DNS 답을 허용합니다. 모델 디스커버리 쪽(src/codex/catalog/provider-fetch.ts, src/server/management/provider-routes.ts)은 isCanonicalUrl: isRegistryModelDiscoveryUrl을 넘깁니다. 반면 Antigravity 계정 쿼타 경로 fetchAntigravityUsageQuota(src/providers/quota.ts)는 고정 호스트 https://daily-cloudcode-pa.googleapis.com의 v1internal:retrieveUserQuotaSummary / v1internal:fetchAvailableModels를 providerOutboundPost로 치지만, 넘기는 의존성은 모듈 기본값 antigravityOutboundDependencies = {}입니다. 즉 명시 HTTP(S) 프록시 env가 없는 TUN-only Fake-IP에서는 쿼타 probe가 destination policy에서 거절될 수 있고, 그 결과가 UI의 일반 “일시 불가”로만 보일 수 있습니다.

더 조심할 점도 있습니다. isRegistryModelDiscoveryUrl(src/providers/model-discovery.ts)은 레지스트리 modelDiscovery URL만 증명합니다. 레지스트리의 google-antigravity 행(src/providers/registry.ts)은 baseUrl이 같은 Cloud Code Assist 호스트이지만 modelDiscovery 스펙이 없습니다. 그래서 디스커버리용 헬퍼를 쿼타 URL에 그대로 꽂아도 retrieveUserQuotaSummary는 통과하지 않습니다. 이슈가 말하는 “좁은 canonical-destination proof”가 필요한 이유입니다. 추가로 프로바이더 단위 fetchAntigravityQuota는 summary만 outbound를 쓰고, fallback fetchAvailableModels는 일반 fetch를 씁니다. 계정 probe와 프로바이더 probe의 정책·에러 표면이 어긋날 수 있습니다. types/config 분할로 무효화될 이슈가 아니고, #3213 Antigravity 계정 쿼타·account-pool 축과도 맞닿아 release-244 비목표(새 프로바이더, #3689, #3719)와도 충돌하지 않습니다.

라인 2610 - antigravityOutboundDependencies 기본값이 빈 객체라 Fake-IP canonical 증명이 항상 꺼진 채 출발함
라인 2627 / 2648 - 계정 쿼타 summary·models 둘 다 providerOutboundPost인데 동일 빈 의존성을 넘겨 TUN-only Fake-IP에서 거절될 수 있음
경로 isRegistryModelDiscoveryUrl - 디스커버리 URL만 증명. Antigravity에 modelDiscovery 스펙이 없어 쿼타 URL에는 재사용 불가
라인 2704 - 프로바이더 fetchAntigravityQuota fallback이 raw fetch라 outbound Fake-IP/핀 정책과 어긋남
경로 UI “速率限制数据暂时不可用” - null/throw를 안전한 실패 카테고리로 나누지 않으면 Fake-IP 거절·401·업스트림 오류가 한 문구로 뭉개짐
경로 회귀 - Fake-IP DNS + 프록시 env 없음에서 고정 Google 쿼타 URL이 통과하고, 비관련 private/metadata는 계속 거절되는지 단언하는 테스트가 필요

메인테이너의 판단이 필요한 지점

• 증명을 ANTIGRAVITY_ACCOUNT_QUOTA_BASE + 두 fixed path만 허용하는 전용 헬퍼로 둘지, 레지스트리에 쿼타/discovery URL 목록을 올려 일반화할지
• 프로바이더 fallback fetchAvailableModels도 계정 probe처럼 providerOutboundPost로 통일할지
• UI/API에 Fake-IP·destination-policy 거절용 안전 에러 카테고리를 새로 둘지, 기존 unavailable에 원인 코드만 붙일지
• 수락 전에 Clash TUN 실측을 필수으로 볼지, 소스 정합+단위 테스트(주입 resolveAddresses)만으로 forward-fix할지

너의 추천
수락 방향이 맞습니다. fetchAntigravityUsageQuota / summary 경로에 Google 고정 쿼타 URL만 통과하는 좁은 isCanonicalUrl을 주입하고, TLS·리다이렉트·비관련 private/metadata 거절은 유지하세요. 프로바이더 fallback도 같은 outbound로 맞추고, Fake-IP DNS 답을 주입한 회귀를 추가하세요. UI는 가능하면 destination-policy 거절을 일반 unavailable과 구분하세요. 범위는 src/providers/quota.ts (+ 필요 시 작은 URL proof 헬퍼)와 테스트로 좁히면 release-244에 넣기 좋습니다. 확정 재현 로그가 오면 우선순위를 더 올려도 됩니다.

이 댓글은 grok-bot이 작성했습니다

[lidge-jun]

Partial: the transport slice landed on dev via #3872 (merge ddee5e8b4, carrying @hualiny's #3849) — canonical Antigravity discovery/quota reads are now admitted through a Mihomo IPv6 fake-IP under the TUN transparency exception. Remaining for this issue: authenticated TUN field acceptance and failure classification, so it stays open.