verdier opened a new issue, #44268:
URL: https://github.com/apache/superset/issues/44268
### Problem
Frontend error toasts select server messages, translated permission
messages, and fallbacks inconsistently. This came up while addressing review
feedback on #44238.
`getClientErrorObject` already normalizes API errors, but callers still
implement their own selection rules. Examples include:
- `src/dashboard/actions/dashboardState.ts` (dashboard saving)
- `src/components/Tag/utils.tsx`
-
`src/dashboard/components/nativeFilters/FiltersConfigModal/FiltersConfigForm/ColumnSelect.tsx`
-
`src/dashboard/components/nativeFilters/FiltersConfigModal/FiltersConfigForm/DatasetSelect.tsx`
- `packages/superset-ui-core/src/query/getClientErrorObject.ts`
(`getErrorText`)
Several of these check `message === 'Forbidden'`, whereas `message` may be
absent after normalization of a non-JSON response.
### Concrete example
For a JSON 403 response containing `{"message":"Forbidden"}`, normalization
produces both `message` and `error`. For a non-JSON 403 response, normalization
can produce `error: 'Forbidden'` without `message`.
The existing dashboard-save tests explicitly cover different output for
these two cases: a permission message for JSON, and a generic error prefix
followed by `Forbidden` for non-JSON. In #44238, the publish action needs to
preserve its previous permission toast for both cases, requiring another local
condition.
This is a consistency and maintainability issue in presentation, not a
change to authorization enforcement.
### Proposed improvement
Consolidate message selection in the existing shared error utilities rather
than adding more per-component conditions or another competing helper:
- Preserve HTTP status consistently when normalizing both JSON and non-JSON
responses. The non-JSON branch currently spreads a `Response`, which does not
reliably preserve properties such as `status`.
- Define and test a shared precedence policy for contextual translated
messages, normalized server messages, and a caller-provided translated fallback.
- Where a contextual permission message is appropriate, use the HTTP status
rather than matching the English string `Forbidden`.
- Preserve useful validation messages and existing safe handling of HTML
responses.
- Migrate callers incrementally, reviewing intentional behavior differences
rather than mechanically replacing every condition.
Keep error lifecycle decisions local: a component should still decide
whether to show a toast, preserve form values, reset loading state, or rethrow.
The shared utility should select the display text, not globally catch or
swallow failures.
### Validation
Cover JSON and non-JSON 403 responses, validation responses, server failures
with and without a useful message, network errors, and translated fallbacks.
Verify existing caller behavior during migration.
### Scope and related work
This is a follow-up to the narrow fix in #44238, not a request to expand
that PR. No backend API change is proposed.
#33500 is related to error-message handling and HTML detection, but
describes a separate symptom; this proposal focuses on consolidating message
selection across frontend callers.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
