nevzheng commented on PR #11959: URL: https://github.com/apache/gravitino/pull/11959#issuecomment-4940358604
Following up on Rory's point that a federated REST catalog shouldn't be treated as broken just because its remote is momentarily unreachable — I've split the failure modes into a proper taxonomy: - **Bad `warehouse` value** (server reachable, rejects the selector) → `IllegalArgumentException` / **HTTP 400**. User misconfiguration, unchanged. - **Backend unreachable or 503** (create-time *or* later operations) → `ConnectionFailedException` / **HTTP 502 Bad Gateway** (error code 1007). A downstream-dependency outage, not a Gravitino bug and not a user error. - **Anything else** → still 500. So create-time validation no longer conflates "your config is wrong" with "the remote happens to be down" — the latter is now a distinct, honest 502. The translation happens once in the Iceberg layer (`RESTException` → `ConnectionFailedException`); the server maps the type to 502 and the Java client reconstructs it from code 1007, so both the create and operation paths report it consistently. Covered by an IT for each path (unreachable-at-create and operation-on-dead-backend) plus a unit test on the translation. Full `CatalogIcebergRestIT` run is green. Note: the base `RESTException` (bare transport failure) and `ServiceUnavailableException` (503) both map to 502; other REST subtypes (4xx caller errors, `ServiceFailureException`) still pass through — I've filed a follow-up to sweep those mappings across all catalog backends rather than expand scope here. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
