lxbme opened a new pull request, #3428: URL: https://github.com/apache/apisix-dashboard/pull/3428
**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): > Route `vars` invalid JSON: with zod resolver attached, React Hook Form ignores Monaco field-level `validate` rules, causing `JSON.parse` to throw inside `mutationFn` — on `routes/add`, the Add click silently fails. Root cause is a three-layer misalignment: 1. The Monaco editor component (`FormItemEditor`) does define a field-level JSON-syntax `validate` rule — but react-hook-form's documented behavior is to ignore all field-level rules once a `resolver` is attached, and the route forms use `zodResolver`. The rule is dead code there. (The plugin editor drawer's form has no resolver, which is why the very same component validates correctly in that context.) 2. The zod schemas typed `vars` as a plain `z.string().optional()` — any text passes. 3. `produceVarsToAPI` then runs `JSON.parse` inside `mutationFn`. On invalid JSON it throws a `SyntaxError` before any request is built — a non-axios error the interceptor never sees — so clicking Add/Save produced no toast, no field error, no navigation: nothing. ### Change Single schema file, `src/components/form-slice/FormPartRoute/schema.ts`: a shared `varsJSONString` type — `z.string().optional()` refined with a JSON-syntax check (empty/whitespace allowed, message `JSON format is not valid`) — used by both `RoutePostSchema` and `RoutePutSchema`. Inferred types are unchanged (`string | undefined`), so no consumer changes. Invalid JSON now surfaces as a field error under the Monaco editor before any request is attempted (`FormItemEditor` already renders `fieldState.error?.message`, and the forms already set `shouldFocusError`), and `JSON.parse` in the submit pipeline only ever sees validated strings. The layering is deliberate: **syntax** errors are caught by the frontend schema; **semantic** errors (vars must be a valid APISIX expression array) stay with the Admin API, whose 400 `error_msg` the axios interceptor already surfaces as a toast. No new catch layers. ### Tests New e2e spec `e2e/tests/regression/routes.vars-invalid-json.spec.ts` (written first and verified failing against the old behavior): - fills a complete valid Add Route form but with broken JSON in vars, clicks Add; - asserts the field error appears, the page stays on `/routes/add`, and — via a request-counting route — that **zero** POSTs reached the Admin API; - then fixes the JSON in the same form and asserts the submit succeeds (exactly one POST, success toast, detail page). Also ran locally: routes CRUD suites, `routes.clear-upstream-field`, `services.routes.crud`, and the full `e2e/tests/regression/` folder — 34/34 green. **Related issues** Part of #3417 (item: "Route vars invalid JSON silently fails on Add" 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]
