GitHub user jerryshao added a comment to the discussion: Error taxonomy: we collapse every failure into HTTP 500 — a gateway shouldn't
>Authorization vs authentication (401 vs 403). Today 401 is effectively dead >taxonomy and backend auth failures (Kafka AuthorizationException, JDBC >SQLState 28, Iceberg 401/403) collapse to 500. How do we surface upstream >authz failures vs Gravitino's own access control? It depends on how we treat such data source issues. If we return 401/403, 1) It will mix with Gravitino's own authn/authz error, making it hard for the user to understand; 2) some systems will treat 401 as a specially case to do some additional process like relogin, reissue the tickets, which will not work for the data sources Gravitino connected. So it is debatable to change this semantics. > Rate limiting / backpressure (429 + Retry-After). Exists only for the lineage > sink today — should the gateway propagate upstream throttling? I think it makes sense. But, we don't support rate control / backpressure for now. We'd better adding rate control before we support these two error codes. > Timeouts (504 vs 503). Distinguish "upstream slow" from "upstream down"? Again, itself makes sense. If we can differentiate these two errors, we can have two different codes. > Non-obvious retriability traps the converters must encode: Iceberg > CommitStateUnknownException → never auto-retry (possible double-write); > CommitFailedException → retry the whole commit, not the request; Kafka > UnknownTopicOrPartitionException is marked retriable but is semantically 404; > JDBC — classify on the marker hierarchy before SQLState (class 08 is > ambiguous). This should be treated case by case. We'd better not add the retry codes for all the cases. We need to separate into case by case thing. > Error-message hygiene — sanitize what crosses the boundary to callers > ([CWE-209](https://cwe.mitre.org/data/definitions/209.html)) while keeping > full detail in logs. This is a good thing. > Error-code stability — once clients depend on codes they become API surface; > how do we version them (per AIP-193's backwards-compat guidance)? We can use OpenAPI to track the stability. But I cannot figure out a better solution. Maybe we can have more discussion on this. GitHub link: https://github.com/apache/gravitino/discussions/11982#discussioncomment-17617466 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
