lxbme opened a new pull request, #3448: URL: https://github.com/apache/apisix-dashboard/pull/3448
Please answer these questions before submitting a pull request, **or your PR will get closed**. **Why submit this pull request?** - [x] Bugfix **What changes will this PR take into?** This closes two more "Test-suite gaps" items of the frontend review in #3417. **1. General round-trip invariant (`e2e/tests/regression/form.round-trip-invariant.spec.ts`)** There was no general "create → read → no-op edit-save → deep-diff" test — the class of bug that #3414 (SSL mTLS client block wiped on edit-save) belonged to. Existing specs pin specific known losses one field at a time; this is the parametrised guard that catches future ones. For each resource it seeds a rich record via the Admin API, opens the detail page, clicks Edit then Save without changing anything, reads the record back, and asserts it is unchanged. Both sides are Admin-API-stored values (already gateway-canonicalised), so the comparison only drops the server-managed timestamps and folds any array-form upstream `nodes` back to the object-map form — a benign representation reshuffle is not a false failure, but a dropped or emptied field is. Covered: route, service, upstream, consumer, consumer_group. **SSL and Secret are deliberately excluded** — their private key / manager tokens are write-only (never returned by the API), so a pure no-op save cannot reproduce them; the SSL client-block case is already covered by `ssls.noop-edit-preserves-client.spec.ts`, which re-enters the key. Note on the consumer case: it seeds username/desc/labels only. A consumer with a `key-auth` plugin does **not** round-trip cleanly — a no-op edit-save comes back with a *different* `key` (the form appears to drop the write-only key and the gateway regenerates one). This is flagged for separate investigation: if an unrelated edit to a consumer rotates its auth key, existing clients using the old key would break. The harness surfaced it; it is out of scope for this test PR. **2. Mutation-failure feedback for update and delete (`e2e/tests/regression/form.mutation-failure-error.spec.ts`)** The HTTP-error-with-body toast (via the Axios interceptor) was pinned only for route *create*. Network-level failures already had update/delete/timeout coverage in `network-error.mutation-toast.spec.ts`, but the distinct HTTP-500-with-`error_msg` path was create-only. Two tests are added: an edit-save that gets a 500, and a delete that gets a 500, both asserting the error toast appears. **Related issues** Part of #3417 **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 The round-trip harness's sensitivity was demonstrated during development: the consumer + key-auth case went red on the changed key before it was narrowed to the non-sensitive fields. Verified with `tsc`, ESLint, the unit suite, and the full e2e suite. Remaining test-suite-gap items, each larger and out of this PR: cross-browser / pinned-image CI, and the `waitForTimeout` removal + parallel-safety refactor. -- 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]
