Why is isValid false when there are no errors?

[thany]

Just need to know - under what conditions after validation has succeeded and there are no errors, can isValid remain false?

This problem (if it's a problem) occurs only when filling out a form with Cypress, but not manually. This makes me suspect a race condition. But why can I see isValidating going from true and back to false, produce no errors, and keep isValid at false? How? Why?

[tamish-max]

isValid is not just “errors is empty right now”.

A few cases where you can see no errors and still have isValid === false:

• validation for the relevant fields hasn’t actually been triggered yet (depends on mode / reValidateMode)
• async validation finished for one snapshot, but a newer change already made the form stale again
• Cypress updated inputs in a way that doesn’t match real user events (blur, change, etc.), so RHF never reached the same validation path as manual typing
• values were set programmatically without shouldValidate: true

In E2E tests this is especially common with mode: 'onBlur' / onTouched: the field can look fine and errors can be empty, but isValid won’t flip until the blur/validation lifecycle actually runs.

So I’d first check the form mode and whether Cypress is reproducing the same blur/change sequence as a real user.

[harshagarwalnyu]

Yeah, this is a classic race condition often seen in fast automation environments like Cypress. The reason is that isValid is a derived state that updates asynchronously in a microtask after the validation cycle completes: it doesn't always flip to true at the exact same moment your error object clears.

When you see isValidating go from true to false and errors is empty, RHF has finished the validation, but React might not have flushed the state update for isValid to your component yet. Cypress is fast enough to catch that intermediate frame.

First, make sure you are actually destructuring isValid from formState. RHF uses a Proxy to optimize performance, so if you don't destructure it, the hook won't subscribe to those updates and it'll stay false:

// This destructuring is required for subscription
const { formState: { isValid, errors } } = useForm({ 
  mode: 'onChange' 
});

For Cypress specifically, stop checking the isValid variable directly. Instead, rely on Cypress's retry-ability by asserting on the UI state, like the submit button status. Cypress will automatically retry the assertion until the state finishes updating:

// ❌ Avoid checking raw state
// expect(formState.isValid).to.be.true;

// ✅ Assert on the UI
cy.get('input[name="email"]').type('test@example.com');
cy.get('button[type="submit"]').should('not.be.disabled');

If you really need the state, you can wait for the validation to settle by checking isValidating first. But usually, letting Cypress handle the retries on the DOM elements is the most robust path.

[jacksjm]

One useful way to narrow this down is to distinguish an actual validation failure from a form-state subscription or event-sequencing issue.

I would check three things:

1. Destructure "isValid", "isValidating", and "errors" during render so React Hook Form subscribes to those state properties.
2. Check "mode" and "reValidateMode", and confirm Cypress reproduces the same change/blur sequence as manual input.
3. Temporarily call "await trigger()" after entering the values and compare the result with the observed "isValid" state.

For the Cypress test, prefer a retryable DOM assertion:

cy.get('[name="email"]').type('test@example.com').blur();
cy.get('button[type="submit"]').should('not.be.disabled');

If an explicit "trigger()" resolves the discrepancy, investigate the event sequence and validation mode. If it does not, a minimal reproduction with the resolver and default values would help isolate the remaining issue.

Also, "errors" being empty is not, by itself, proof that the complete form has passed validation.