Repository navigation
fix(google): classify "User location is not supported" as location/permission error instead of invalid_request #3467
Description
Activity
Issue reopened
The report now contains the information required by the automated check. Thanks for updating it.
리뷰 · 우선순위 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, HEAD3a9c4d297)의 분류는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(원하면 codelocation_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_PRECONDITIONfixture가 없어 이 회귀를 지금 스위트가 잡지 못한다.심볼 location_not_supported - 공개 코드로 아직 없고, 이슈가 기대한 이름을 쓰려면
classifyError쪽 code 계약을 새로 정해야 한다.메인테이너의 판단이 필요한 지점
- 공개 타입을
permission_error로 둘지, 새 codelocation_not_supported까지 노출할지 - 분류를 Antigravity 전용으로 둘지
classifyGoogle공통(Vertex 포함)으로 둘지 - 클라이언트/로그가 invalid_request에 의존하는지가 있어 타입 변경의 호환 범위
너의 추천
classifyGoogle에 location/FAILED_PRECONDITION분기를 넣고tests/google-errors.test.ts로 고정한 작은 PR을 받으세요. 공개 타입은 기존 403 경로와 맞춰permission_error+ 분명한 메시지 우선,location_not_supportedcode는 원하면 같은 PR에 추가하세요. help wanted로 두기 좋은 크기의 provider 버그입니다.이 댓글은 grok-bot이 작성했습니다
- 공개 타입을
Environment/evidence from a separate deployment, redacted:
- OpenCodex 2.42.0 in a Debian 12 Kubernetes container.
- Provider:
google-antigravity; model:gemini-3.8-flashwithreasoning_effort=high(the same result was observed withgemini-3.7-flash). - Five stored OAuth accounts were tested independently. All had access and refresh credentials present, with
needsReauth=falseanddisabled=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_PROXYare 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.
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 usetopermission_errorwith codelocation_not_supportedand proper diagnostic warnings) is implemented in #3469 with full test coverage and all green CI checks ondev.
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 400withFAILED_PRECONDITION: User location is not supported for the API use.), OpenCodeX classifies it asAntigravity invalid requestand returnstype: "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
opencodex start --port 10100).google-antigravityprovider.User location is not supported for the API use.Provider error 400: Antigravity invalid request: User location is not supported for the API use.withtype: "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