GitHub user markhoerth added a comment to the discussion: Error taxonomy: we collapse every failure into HTTP 500 — a gateway shouldn't
Weighing in from the product side, since Nevin asked how this shows up in real engagements. The short answer: it shows up early, and it shows up as a trust problem rather than a technical one. In enterprise evaluations, especially at large financial services organizations, the platform and SRE teams wire retries, circuit breakers, alerting, and on-call routing to status codes before anything goes near production. When every failure is a 500, none of that automation can distinguish "back off and retry" from "page a human" from "open a ticket with the vendor." We have already seen the adjacent version of this ask: the health endpoints added in `#10840` came directly from a customer's load balancer requirements. Error semantics are the same class of requirement, and I expect it to be raised explicitly as deployments deepen. A gateway that cannot say whose fault a failure is creates integration friction at exactly the wrong moment in an evaluation. I also looked at how our own Web UI V2 handles this today, and it makes the case better than any hypothetical: 1. The UI's fallback message for a 500 is "Server error, unable to connect Gravitino!" (`web-v2/web/src/lib/utils/axios/checkStatus.js`). So when a customer's Hive Metastore is down and the server collapses it into a 500, our own UI tells the user that Gravitino is broken. We make the misattribution for ourselves. 2. The counterfactual already exists in the codebase. The one status the server emits with real meaning is 401, and the UI recovers from it gracefully: the response interceptor clears tokens and triggers re-auth. Where the taxonomy exists, the client recovers. Where everything is 500, it cannot. checkStatus even has a reasonable 503 message that users essentially never see, because we almost never send 503. 3. The UI's retry machinery (`axiosRetry.js`) is disabled by default (`isOpenRetry: false`), GET-only, and blind to status codes. Even if we turned it on, there is no signal from the server worth keying it on. Nevin's observation about the Java client extends to the UI for the same root cause. 4. Server exception text flows verbatim into user-facing toasts. checkStatus even does string surgery on the message body (searching for the substring "reason" and stripping brackets) to clean it up after the fact. Raw internal messages are effectively UI copy today, which strengthens the case for the public vs internal split. On sequencing, two additions: First, +1 on doing Phase 0 now. It is small, touches one layer, changes no client contracts, and fixes the worst misattribution for every entity at once. I will advocate for prioritizing it. Second, PR `#10387` (log and error message quality polish, currently open) touches many of the same message sites the Phase 2 converters will rewrite. Merging it first avoids a painful rebase later, and I would suggest treating it as the reference for message standards going forward. Which brings me to the "discipline" register of Nevin's timeline. Since server error messages are user-visible copy, I would like to see us codify message content standards alongside the taxonomy: consistent phrasing conventions (the ones `#10387` establishes), plus a simple template of what failed, in which domain, and what the caller can do about it. That belongs in `CONTRIBUTING.md` and in the standard review questions, next to "is it retriable" and "is it ours or a dependency's." It costs nothing and stops both problems, semantic and linguistic, from spreading further. Happy to help work through the error-code stability question as well, since once clients depend on codes they become API surface, and that is a product commitment as much as an engineering one. GitHub link: https://github.com/apache/gravitino/discussions/11982#discussioncomment-17608529 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
