GitHub user nevzheng added a comment to the discussion: Error taxonomy: we collapse every failure into HTTP 500 — a gateway shouldn't
## Horizon / timeline I don't see this as a fire drill — but it's a compounding issue we should commit to resolving over roughly **the next year**, in three registers: - **Immediately — discipline.** Integrate error design into how we write and review code: make "what domain is this failure, is it retriable, is it ours or a dependency's?" a standard review question. Costs nothing and stops the pattern from spreading further. - **Short-to-medium term — policy.** Adopt a lightweight error-handling + review policy (fault domains, retriability, public vs internal, our-errors vs dependency-errors), optionally nudged by a lint/Checkstyle rule. - **Medium term — remediation.** Work the remediation plan above: the server-side quick win, the taxonomy, per-catalog converters, then client retry. - **Long term.** I don't expect this to become a long-term problem *unless we ignore it* — the cost only compounds if we let it sit. **Why a real horizon and not "someday":** I believe this will affect enterprise engagements. Large customers need proper error handling to deploy Gravitino into — and integrate it with — their existing systems; their automation and their on-call depend on it. On-call's whole job is to firefight, and you can't firefight when every failure is the same generic 500 with no signal of whose fault it is or whether to retry. Clean error semantics are what let their operators (and ours) act instead of guess. *(Checking with Mark on how this has shown up in real engagements.)* GitHub link: https://github.com/apache/gravitino/discussions/11982#discussioncomment-17601971 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
