fix(web): show nested Zod errors in FormMessage - #16317
nkabardin merged 10 commits into
Conversation
Sorry, something went wrong.
Array-level and item errors from Zod 4 leave error.message undefined, so the shared FormMessage rendered nothing. Walk root and nested field errors, and drop the eval-template workaround that duplicated that logic. Co-authored-by: Nikita Kabardin <nikita@kabardin.com>
|
Doubt this: getFieldErrorMessage prefers root then the first nested child, so a parent FormMessage on an array can show an item error when there is no array-level message (eval template now has both a parent FormMessage and per-item ones). Also type is treated as a nested error only when it is an object, which is a heuristic for Zod union paths vs RHF metadata. |
Sorry, something went wrong.
🟢 AWS preview image pushedArgo CD is rolling it out — the environment is usually ready within a URL: https://pr-16317.preview.langfuse.com (signs you in automatically; opt out with /auth/sign-in?autoSignIn=false) URL not loading / 404? Full debug guide — deploy allowlist, Logs (needs preview-cluster kubectl access): kubectl -n langfuse-pr-16317 logs -f deploy/langfuse-pr-16317-web # web
kubectl -n langfuse-pr-16317 logs -f deploy/langfuse-pr-16317-worker # workerAdd --previous for a crashed container, --tail=200 to limit, or Synthetic preview data only. Never add production data to public accounts. |
Sorry, something went wrong.
Parent FormMessage on categories was repeating per-item empty-value errors. Only render it when the array itself has a message or root message.
|
What to doubt in review
|
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM with one nit. The previously flagged categories duplicate-warning issue in template-form.tsx has been fixed by gating the parent FormMessage to array-level errors only. A new inline comment flags the identical duplicate-warning pattern in the untouched variable-mapping-card.tsx (sibling call site with the same bare array-level FormMessage) — purely cosmetic and not a submit-blocking issue, so it doesn't need to hold up this PR.
Extended reasoning...Overview
This PR changes how FormMessage (web/src/components/ui/form.tsx) resolves an error message from a react-hook-form/Zod error object: instead of reading only error.message, it now recursively walks message → root → nested children. It updates template-form.tsx to use the shared primitive instead of a local workaround, and updates WidgetForm.tsx/widgetFormSchema.ts to also check metrics.root.message when deriving the save-blocked reason text. All changes are confined to client-side form-rendering/UX code with client tests added for the new recursive behavior.
Security risks
None. This is purely presentational error-message rendering; no data handling, auth, or trust-boundary code is touched.
Level of scrutiny
Low-to-moderate. This is a UI-only bug fix with narrow blast radius (form error display), reasonable test coverage (form.clienttest.tsx, widgetFormSchema.clienttest.ts), and the riskiest part — the new generic recursive fallback in a shared primitive — was specifically probed for regressions across its various callers, since a shared, generic change like this can surface latent duplicate-render issues at other call sites that weren't touched by the PR itself (as it did here for variable-mapping-card.tsx).
Other factors
The author (via a follow-up agent commit) already addressed my prior review comment about the template-form.tsx categories duplicate by gating the parent FormMessage. The newly found duplicate-warning pattern in variable-mapping-card.tsx is structurally identical but purely cosmetic (validation/submit-blocking behavior is unaffected), so it doesn't rise to a merge-blocking severity, though it's worth the author's attention as a quick follow-up.
Sorry, something went wrong.
|
🧹 Preview environment torn down after 2 days of inactivity (last update 2026-08-20T16:25:14Z). Re-add the preview label to redeploy. |
Sorry, something went wrong.
Parent FormMessage on eval variable mappings was repeating per-row JsonPath warnings. Gate array-level FormMessages with a shared helper.
|
What to doubt in review
|
Sorry, something went wrong.
RHF FieldPath does not include Zod nested keys like .root and .config, so the FormMessage tests failed web typecheck in CI.
…com/langfuse/langfuse into lfe-15322-formmessage-nested-errors
🟡 Live preview: pr-16317.preview.langfuse.com
What does this PR do?
When an array field has both item-level and array-level Zod errors, react-hook-form stores the array message on root and leaves error.message undefined. FormMessage only read error.message, so the form blocked submit with no visible text.
This walks message → root → nested children so the shared primitive shows those errors. The eval template category workaround is now a normal FormMessage. Widget save-reason copy also prefers metrics.root.
Companion toast work is already in #16313.
Type of change
Mandatory Tasks
Checklist
Test this
Preview: https://pr-16317.preview.langfuse.com
Data: demo project is enough.
Sandbox: http://localhost:3000 same path.
Slack Thread
Greptile Summary
This PR updates shared form error rendering to discover Zod/react-hook-form messages stored under root or nested child paths, replacing the evaluator-specific workaround and extending widget save-reason extraction.
Confidence Score: 5/5
The PR appears safe to merge, with the nested validation behavior covered by focused tests and no actionable defects identified.
The shared renderer preserves direct-message and child fallback behavior while adding explicit root handling, and the evaluator and widget consumers consistently adopt the intended error priority.
Reviews (1): Last reviewed commit: "fix(web): show nested Zod errors in Form..." | Re-trigger Greptile