VeeValidate v4 schema validation and asynchronous field synchronization

Direct answer

Yes, calling setFieldError will make the field invalid and meta.valid false even if the Yup/Zod schema is satisfied. A manual error is stored on the field and is merged into the field’s error state. The schema-driven validation cycle can later overwrite that manual error on the next validation run for that field.

If an asynchronous server check fails but the schema remains satisfied, meta.valid is false while the async check is pending and becomes false after the async check resolves with an error. When the schema itself is valid, the field’s validity is determined by the union of schema errors and any manual errors you set.

Confirmed behavior

• useForm({ validationSchema }) with a Yup/Zod schema that contains an async test runs that test on change, blur and submit. VeeValidate exposes meta.pending and meta.valid per field and blocks form submission until all async validators settle.
• Field values are updated immediately on input. Validation does not wait to mutate values.
• VeeValidate v4 does not provide built-in stale-promise cancellation for async validators. If the field changes mid-validation, an earlier promise can still resolve and update the error state unless you debounce or track a request id yourself.

Likely explanation, not confirmed

VeeValidate does not automatically discard stale async results. The assumption that earlier promises are ignored is not documented. Treat automatic discarding as an assumption and guard it yourself for both validation and synchronization.

Steps for this case

1. Put server-side checks inside the schema async test rather than using a separate watcher + setFieldError. This keeps schema state and async state in one cycle and avoids redundant full-form revalidation.
2. If you must synchronize another field after an async fetch, watch the source field and call setValue from the form context after the async call resolves. Do not call setFieldError to represent a schema rule.
3. Surface meta.pending to the UI and debounce async calls to reduce network traffic and race conditions.
4. When using manual errors, clear them explicitly before the next schema validation run or prevent the schema from re-validating that field until you are ready.

One missing diagnostic detail that changes the recommendation: are you running the server check as an async test inside the Yup/Zod schema, or as an independent watcher that calls setFieldError? The safe pattern differs for the two.