Describe the bug
When a field has a field-level onMount validator and is linked to another field, the onMount error is never cleared, even when the other validators on that field run successfully via the linked-field mechanism and report the field as valid.
The result is that field.state.meta.errors keeps surfacing the stale mount-time error and isValid stays false indefinitely or until you touch the field. This also propagates to form.state.isValid, breaking submit-button enablement and any UI that depends on per-field validity.
Possibly related to #689, #903
Your minimal, reproducible example
https://stackblitz.com/edit/vitejs-vite-ywiic5qt?file=src%2FApp.tsx
Steps to reproduce
- Open the StackBlitz repro.
- Observe the initial state: password is empty, confirmPassword defaults to "password". The confirmPassword field's onMount validator correctly reports "Passwords do not match" in
errorMap.onMount, and isValid is false. This is expected.
- Type "password" into the Password input. Do not touch the Confirm Password input.
- The onChange validator on confirmPassword runs via
onChangeListenTo: ["password"] and correctly returns undefined — errorMap.onChange is now undefined.
- Bug:
errorMap.onMount still shows "Passwords do not match", and both confirmPassword.isValid and form.isValid remain false, even though both validators on the field, given the current values, return undefined.
Expected behavior
As a user, I expected the onMount error to clear once the field's other validators run successfully via the linked-field mechanism, but I am seeing the onMount error persist indefinitely (or until it's touched), leaving the field marked as invalid even though all of its validators agree that it is valid.
How often does this bug happen?
Every time
Platform
- OS: macOS
- Browser: Google Chrome
- Version: 146.0.7680.178
TanStack Form adapter
react-form
TanStack Form version
v.1.29.0
TypeScript version
v6.0.2
Additional context
Not sure whether to classify this as a bug or a design choice. onMount only clearing on direct value changes could be a deliberate "the user must acknowledge this field" rule. But it does feel like an edge case worth revisiting, given that onChangeListenTo / onBlurListenTo exist specifically for cross-field patterns.
If the current behavior is intentional, an opt-in to let successful linked-field revalidation clear the stale onMount slot would be very helpful. The only workaround I've found is to manually clear the slot via setMeta from a listener on the source field, which is fragile and easy to forget.
Describe the bug
When a field has a field-level
onMountvalidator and is linked to another field, the onMount error is never cleared, even when the other validators on that field run successfully via the linked-field mechanism and report the field as valid.The result is that
field.state.meta.errorskeeps surfacing the stale mount-time error andisValidstays false indefinitely or until you touch the field. This also propagates to form.state.isValid, breaking submit-button enablement and any UI that depends on per-field validity.Possibly related to #689, #903
Your minimal, reproducible example
https://stackblitz.com/edit/vitejs-vite-ywiic5qt?file=src%2FApp.tsx
Steps to reproduce
errorMap.onMount, and isValid is false. This is expected.onChangeListenTo: ["password"]and correctly returns undefined —errorMap.onChangeis now undefined.errorMap.onMountstill shows"Passwords do not match", and bothconfirmPassword.isValidandform.isValidremain false, even though both validators on the field, given the current values, return undefined.Expected behavior
As a user, I expected the
onMounterror to clear once the field's other validators run successfully via the linked-field mechanism, but I am seeing theonMounterror persist indefinitely (or until it's touched), leaving the field marked as invalid even though all of its validators agree that it is valid.How often does this bug happen?
Every time
Platform
TanStack Form adapter
react-form
TanStack Form version
v.1.29.0
TypeScript version
v6.0.2
Additional context
Not sure whether to classify this as a bug or a design choice.
onMountonly clearing on direct value changes could be a deliberate "the user must acknowledge this field" rule. But it does feel like an edge case worth revisiting, given thatonChangeListenTo/onBlurListenToexist specifically for cross-field patterns.If the current behavior is intentional, an opt-in to let successful linked-field revalidation clear the stale onMount slot would be very helpful. The only workaround I've found is to manually clear the slot via setMeta from a listener on the source field, which is fragile and easy to forget.