lxbme opened a new pull request, #3424:
URL: https://github.com/apache/apisix-dashboard/pull/3424
**Why submit this pull request?**
- [x] Bugfix
- [ ] New feature provided
- [ ] Improve performance
- [ ] Backport patches
**What changes will this PR take into?**
### Problem
This addresses one item from the tracking issue #3417 (Error handling /
resilience):
> Network-level failure (Admin API unreachable/timeout) of any mutation
gives zero feedback: the interceptor only handles err.response errors
(src/config/req.ts), the shared QueryClient has no MutationCache.onError
(src/config/global.ts), and 25 of 26 useMutation sites have no local onError.
Root cause: such failures reject without `err.response`, and the axios
response interceptor in `src/config/req.ts` (the app's only global error toast)
was gated on `if (err.response)`, so the entire responseless error class was
silently dropped — buttons appeared to do nothing when the backend was down.
### Changes
1. **`src/config/req.ts`** — toast on responseless errors (excluding request
cancellation) in the response interceptor.
Note: the tracking issue proposed `MutationCache.onError` on the shared
`QueryClient`. During implementation and manual testing we found that **deletes
bypass react-query entirely** — `DeleteResourceBtn` issues a raw `req.delete`
with no `.catch` — so a `MutationCache`-level fix leaves every delete action
silent. The fix therefore landed one level lower, at the axios interceptor: the
single choke point every request path flows through (`useMutation` sites, the
raw delete, and query refetches alike). HTTP errors keep flowing through the
existing branch untouched.
2. **`src/routes/routes/detail.$id.tsx`** — removed the local `onError`
whose toast duplicated the global one (failed edits showed two toasts). Both of
its error classes (HTTP `error_msg` and network `err.message`) are covered by
the interceptor.
3. **`src/config/constant.ts` + `src/config/req.ts`** — added a 60s
client-side timeout (`API_TIMEOUT_MS`) to the axios instance. Without it (axios
default `0`), a *hung* backend — connection accepted but response never sent —
kept requests pending until the browser gave up (minutes) with no feedback. The
timeout aborts client-side with no response, which the new interceptor branch
then surfaces as a toast.
### Why the timeout is a hardcoded stopgap (not configurable yet)
The dashboard currently has **no runtime configuration mechanism** for
request behavior: it ships embedded in APISIX binaries, and values like
`API_TIMEOUT_MS` are compile-time constants — end users cannot adjust them
without rebuilding. A proper fix is a runtime-configurable setting (e.g. next
to the Admin Key in the Settings modal, persisted the same way), but that
requires UI design and touches i18n across 5 locales, so it is deliberately
left to a follow-up.
The interim value is deliberately generous (60s) because:
- Admin API operations are metadata CRUD and normally complete in
milliseconds;
- a client-side timeout does **not** cancel the server-side operation — a
timed-out mutation may still have succeeded — so false timeouts must stay rare.
Note for reviewers: this is technically a behavior change for any request
legitimately exceeding 60s; we consider that pathological for a metadata API,
but it is called out here explicitly.
### Tests
New e2e spec `e2e/tests/regression/network-error.mutation-toast.spec.ts`:
- consumer create (a `useMutation` path): aborted request → error toast, no
navigation;
- consumer delete (the raw `req.delete` path that bypasses react-query):
aborted request → error toast, no success toast, resource untouched on the
backend;
- route edit: exactly **one** error toast (pins the double-toast removal);
- consumer create against a stalled (never-responding) request: timeout
toast appears after the 60s timeout fires. ⚠️ This test genuinely waits out the
60s timeout (~1 min of CI time) — the value is compile-time, so this is the
only honest way to exercise the real code path. It can shrink to seconds once
the timeout becomes runtime-configurable in the follow-up.
**Related issues**
Part of #3417 (item: "Network-level failure of any mutation gives zero
feedback" under Error handling / resilience). Does **not** close the tracking
issue.
**Checklist:**
- [x] Did you explain what problem does this PR solve? Or what new features
have been added?
- [x] Have you added corresponding test cases?
- [ ] Have you modified the corresponding document?
- [x] Is this PR backward compatible? If it is not backward compatible,
please discuss on the mailing list first
--
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]
