Sign-up and forgot-password keep a stale server error on screen after a resubmit that fails client-side validation

[dawsontoth]

Summary

SignUp and ForgotPassword put their server-failure text in react-hook-form's root error and
clear it with clearErrors('root') inside the submit handler. handleSubmit never calls that
handler when the resolver rejects, so a submission that fails client-side validation leaves the
previous server failure on screen next to the fresh field error.

Reproducing

1. Sign-up: submit with an email that already exists → the form shows User already exists above
   the submit button (correct).
2. Clear the email field, or make it invalid, and submit again.
3. Please enter a valid email address. appears on the field — and User already exists is still
   there, describing an attempt that never left the browser.

ForgotPassword has the same shape (handleSubmit(submitForm) with the clear on the valid path
only), and now has one more root-error source since #1676's client fix routes retryable failures
there.

Why it isn't fixed alongside #1676

SignIn had the same defect and it was fixed there, by hanging the clear off handleSubmit's
second (invalid) argument — but sign-in keeps its failure in component state, not in RHF's root.
The same fix does not work for the RHF-root forms: extending
handleSubmit(submitForm, () => clearErrors('root')) to SignUp was tried and the test failed —
the root error is still rendered after a resolver-rejected resubmit. So these two need a different
mechanism (clear on field change, or move both onto component state the way SignIn now is), which
is a bigger change than that fix warranted and is why it was scoped out by the review's adjudication
rather than bundled in.

Note the repo's own comment at SignUp.tsx asserts the opposite of RHF's documented behaviour here
("handleSubmit reruns the resolver, which only rewrites field errors, so a stale root would
outlive the retry") — worth confirming which is true for the pinned RHF version as part of the fix,
since it determines whether the clear belongs on submit or on change.

Suggested direction

Unify the three auth forms on one mechanism. SignIn's component-state approach is the one with a
working clear-on-invalid story, so moving SignUp and ForgotPassword onto it also removes the
two-patterns-for-three-forms split the #1676 review flagged as an open decision
(signin-error-in-hook-state).

Impact

Cosmetic but confusing: two contradictory messages, one of them stale. No data or security
consequence. Found by the cross-model review on #1676's client fix, adjudicated as pre-existing.

[dawsontoth]

One more reason to prioritise this over "cosmetic": the client fix on #1676 widens the exposure on forgot-password. Before it, the only thing that set a root error there was a CAPTCHA rejection; now every 5xx, 429 and transport failure routes inline too, so the stale-alert window this issue describes is hit by a much more common class of failure than it used to be.

(Noted by the cross-model review on that PR, which adjudicated the defect itself as pre-existing.)

[dawsontoth]

Closing this — I was wrong, and the defect does not exist.

react-hook-form clears a root error on a resolver-rejected resubmit on its own: handleSubmit unsets ROOT_ERROR_TYPE before it branches to the invalid path, then emits the updated errors. Verified empirically against the pinned version (7.85.0) with a minimal probe — set a root error from a successful submit handler, make the field invalid, resubmit; the root error is gone.

What led me to file this was a test of my own that raced: I asserted on the field error appearing, but with the default reValidateMode: "onChange" that error shows up from the change event, before the submit runs. I then queried for the stale alert in that window and found it, and read that as "the clear does not take". It was my test, not react-hook-form.

Sign-in still needs its explicit clearSubmitError on handleSubmits invalid handler, but for a different reason than this issue claimed: its failure lives in component state outside react-hook-form, so RHFs own unset never touches it. The asymmetry between the three forms is therefore correct rather than a gap.

Caught by the cross-model review on the #1676 client fix, which read the react-hook-form source and contradicted me.

[dawsontoth]

Reopening — my previous comment was wrong and the defect is real. I have now reproduced it against the actual SignUp component rather than a minimal useForm, and the difference matters.

The reproduction is committed as a regression test on #1678 (SignUp.test.tsx, "leaves a stale server failure up after an invalid resubmit"), asserting three things together:

1. after a 409 the inline alert reads User already exists;
2. the email is changed to an invalid value and resubmitted, and Please enter a valid email address. appears;
3. post has been called exactly once — so the second submit really was rejected by the resolver rather than re-failing against the server, which is the ambiguity that made my earlier reading unreliable.

The alert is still on screen at that point.

What I got wrong the first time round: I closed this on the strength of a minimal useForm probe where react-hook-form does clear the root error on an invalid resubmit — in both sync and async setError shapes. That probe simply does not reproduce what the real form does, and I treated it as authoritative over a failing test against the real thing. The real component is the evidence; the probe was not.

Also worth recording, because it is what several reviewers proposed and it does not work: adding handleSubmit(submitForm, () => clearErrors("root")) to SignUp leaves the behaviour unchanged. So the fix is not the onInvalid one-liner — the mechanism is specific to these forms and I have not isolated it. That is the open work here.

Sign-in is unaffected: its failure lives in component state outside react-hook-form, and its clear-on-invalid is covered by its own test.

Priority stays P3 — still cosmetic, two contradictory messages — but it is a real one.