Unexpected initial validation errors with validateOnMount:true and async initialValues in vee-validate v4

Direct answer

Yes. In vee-validate v4, validateOnMount: true runs the validation schema as soon as the form mounts, using whatever initialValues exist at that moment. If your values load from an API and are assigned later with setValues or reset, the mount-time check executes against empty or partial values. Required-type rules then emit false-positive errors, and those errors remain in errors until the next validation trigger because vee-validate does not automatically re-run mount validation when initialValues arrive later.

Likely explanation versus confirmed facts

Likely explanation: validateOnMount implements mount-time semantics only; it is not coupled to the first asynchronous initialValues update. This aligns with v4 changing the default from false in v3 to true.

Confirmed facts for this pattern:

• Mount validation sees values present when useForm initializes.
• Later setValues or reset calls do not re-trigger mount validation by themselves.
• Errors clear only on a subsequent validation trigger: field change, blur, submit, or explicit validate().

Recommended pattern for async initial data

1. Set validateOnMount: false in useForm options.
2. After the API response resolves, populate values with setValues or reset.
3. Call await validate() so validation runs against the loaded values.

const form = useForm({
  validateOnMount: false,
  validationSchema,
});

const { data } = await fetchInitialValues();
form.setValues(data);
await form.validate();

If the values are already available synchronously, pass them in initialValues at form construction and you can keep validateOnMount: true.

Verification

Confirm the installed package and how values are supplied:

npm list vee-validate

Log errors.value immediately after mount and again after the API values arrive. False positives that disappear only after an explicit validate() confirm the issue.

One missing diagnostic detail

Are initialValues passed to useForm at construction, or assigned later with setValues/reset? This determines whether you can keep mount validation enabled or should use the async pattern above.

Note: Behavior can vary between vee-validate v4 minor versions and between useForm and the older ValidationObserver pattern. Verify against your installed version before adopting this in production.