fix(google): classify "User location is not supported" as location/permission error instead of invalid_request

[agentHits]

Client or integration

Codex App

Area

Provider adapter

Summary

When Google Antigravity (Cloud Code Assist API) rejects a request due to an unsupported geographic region or datacenter IP (HTTP 400 with FAILED_PRECONDITION: User location is not supported for the API use.), OpenCodeX classifies it as Antigravity invalid request and returns type: "invalid_request_error".

Expected: It should be classified as a location/permission error (location_not_supported / permission_error) rather than an invalid request error, because the request payload/prompt is not syntactically invalid.

Reproduction

1. Start OpenCodeX proxy (opencodex start --port 10100).
2. Configure google-antigravity provider.
3. Send a request from a network location or datacenter IP where Google API restricts access.
4. Upstream returns 400 User location is not supported for the API use.
5. Observe OpenCodeX output: Provider error 400: Antigravity invalid request: User location is not supported for the API use. with type: "invalid_request_error".

Version

2.43.0

Operating system

macOS 15.5

Provider and model

google-antigravity / gemini-3.8-flash

Logs or error output

Provider error 400: {"error":{"message":"Provider error 400: Antigravity invalid request: User location is not supported for the API use.","type":"upstream_error","code":null}}

Screenshots and supporting files

No response

Redacted configuration

No response

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

[github-actions]

Issue reopened

The report now contains the information required by the automated check. Thanks for updating it.

[lidge-jun]

리뷰 · 우선순위 58 / 80

이 이슈는 Google Antigravity(Cloud Code Assist)가 지역/데이터센터 IP 때문에 요청을 거절할 때, OpenCodeX가 그 거절을 “요청이 잘못됐다”로 포장하는 문제입니다. 업스트림은 HTTP 400과 함께 FAILED_PRECONDITION: User location is not supported for the API use. 같은 말을 줍니다. 사용자는 프롬프트나 JSON이 틀린 게 아니라, 그 네트워크 위치에서는 API를 쓸 수 없다는 뜻인데, 지금은 Antigravity invalid request: …로 보이고 공개 에러 타입도 invalid_request_error 쪽으로 갑니다. Codex App에서 보면 “내가 뭘 잘못 보냈지?”로 읽히기 쉽습니다.

현재 dev(2.43.0, HEAD 3a9c4d297)의 분류는 src/adapters/google-errors.ts의 classifyGoogle이 담당합니다. 401/403/429/503 등은 따로 보고, 남는 400·INVALID_ARGUMENT·NOT_FOUND·메시지에 invalid/not found가 보이면 Antigravity invalid request로 묶습니다. FAILED_PRECONDITION이나 “user location is not supported” 전용 분기는 없습니다. 그래서 location 거절이 400으로 오면 Antigravity invalid request가 됩니다. 그 문자열이 다시 src/lib/errors.ts의 classifyError로 들어가면 메시지에 “invalid request”가 들어 있다는 조건과 status === 400 때문에 type: "invalid_request_error"로 고정됩니다. Cursor 쪽은 FAILED_PRECONDITION을 따로 다루는 주석이 src/adapters/cursor/cursor-errors.ts와 src/lib/errors.ts에 이미 있는데, Google/Antigravity 경로에는 같은 세밀함이 없습니다.

고칠 자리는 작습니다. safeAntigravityHttpErrorMessage → classifyGoogle에서 enumStatus가 FAILED_PRECONDITION이거나 메시지에 location-not-supported 문구가 있으면 Antigravity access denied(또는 더 분명한 location 라벨)로 보내고, classifyError도 그 메시지를 permission_error(원하면 code location_not_supported)로 매핑하면 됩니다. tests/google-errors.test.ts에 해당 JSON fixture 한두 개를 추가하면 회귀를 막을 수 있습니다. Vertex와 라벨만 다른 같은 safeGoogleHttpErrorMessage를 쓰므로, Antigravity만 특례로 둘지 Google 공통으로 둘지는 한 번만 정하면 됩니다.

경로 src/adapters/google-errors.ts classifyGoogle - FAILED_PRECONDITION / “user location is not supported”를 400 invalid 버킷에 넣고 있어 지역 거절이 invalid request로 보인다.

경로 src/lib/errors.ts classifyError - 메시지에 “invalid request”가 들어가면 status와 무관하게 invalid_request_error로 가서, 위 라벨을 고치지 않으면 공개 타입도 계속 틀리다.

경로 tests/google-errors.test.ts - location/FAILED_PRECONDITION fixture가 없어 이 회귀를 지금 스위트가 잡지 못한다.

심볼 location_not_supported - 공개 코드로 아직 없고, 이슈가 기대한 이름을 쓰려면 classifyError 쪽 code 계약을 새로 정해야 한다.

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

• 공개 타입을 permission_error로 둘지, 새 code location_not_supported까지 노출할지
• 분류를 Antigravity 전용으로 둘지 classifyGoogle 공통(Vertex 포함)으로 둘지
• 클라이언트/로그가 invalid_request에 의존하는지가 있어 타입 변경의 호환 범위

너의 추천
classifyGoogle에 location/FAILED_PRECONDITION 분기를 넣고 tests/google-errors.test.ts로 고정한 작은 PR을 받으세요. 공개 타입은 기존 403 경로와 맞춰 permission_error + 분명한 메시지 우선, location_not_supported code는 원하면 같은 PR에 추가하세요. help wanted로 두기 좋은 크기의 provider 버그입니다.

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

[nordz0r]

Environment/evidence from a separate deployment, redacted:

• OpenCodex 2.42.0 in a Debian 12 Kubernetes container.
• Provider: google-antigravity; model: gemini-3.8-flash with reasoning_effort=high (the same result was observed with gemini-3.7-flash).
• Five stored OAuth accounts were tested independently. All had access and refresh credentials present, with needsReauth=false and disabled=false.
• Every account returned HTTP 400 with Antigravity invalid request: User location is not supported for the API use.
• Per-account quota/model discovery succeeds, so this is not a 429/quota-exhaustion result.
• HTTP_PROXY/HTTPS_PROXY are configured. A generic public egress probe reported a US location, but that does not prove Google's IP classification or that Google traffic used an identical route.

This corroborates the misclassification reported here across multiple valid account contexts. It does not establish an OpenCodex routing defect or a Google-side root cause: HTTP 400 is correctly not treated as quota failover, and all tested accounts returned the same location/eligibility rejection.

No account identifiers, emails, project IDs, IP addresses, tokens, or private infrastructure details are included.

[agentHits]

Thank you @nordz0r for the detailed independent reproduction and diagnostic corroboration across multiple OAuth accounts.

The fix addressing this exact misclassification (mapping User location is not supported for the API use to permission_error with code location_not_supported and proper diagnostic warnings) is implemented in #3469 with full test coverage and all green CI checks on dev.

[lidge-jun]

Landed via #3608 at c44e187. Google location denials now classify as permission_error / location_not_supported on dev (carry of #3547 / #3469). Closing as completed.