Your code contains @async_model_validator and @async_field_validator, but it seems to be dead code

[Steve973]

Is your feature request related to a problem? Please describe.
I want to validate cypher queries when the LLM generates parameters, but I want it to happen in the retry loop, if possible. The fact that you have async validator decorators indicates that you may be planning for async validation, but the code is not really connected to anything (apparently dead code).

Describe the solution you'd like
I would like to be able to use the async validator decorators and have instructor call them, and have them work for async functions.

Describe alternatives you've considered
I am trying manual validation, but that makes me accept bad input from the LLM and proceeding with it in some way, then only sending a message back with an error to try again, except it's disconnected from the original request. I also tried pydantic-async-validation, but it doesn't work, either. Neither does just putting the regular validator decorators on an async function.

Additional context
These seem to be the same validators in pydantic-async-validation, and if instructor worked with those, that would be fine, as well.

[wWzZb]

I traced this through the current v2 path: the decorators still attach metadata and AsyncValidationError is already retryable, but no parser discovers or awaits the validators.

I can keep the fix narrow: after a non-streaming async client successfully parses a structured response, await the declared validators on the returned model(s), including nested models, and raise AsyncValidationError inside the current retry attempt so the existing reask path handles failures.

One API question before I implement it: when a sync client receives a response model with async validators, should it fail clearly, or preserve the current no-op behavior? I lean toward a clear error rather than silently returning an unvalidated model.

[Steve973]

One API question before I implement it: when a sync client receives a response model with async validators, should it fail clearly, or preserve the current no-op behavior? I lean toward a clear error rather than silently returning an unvalidated model.

I think that your preference is the most reasonable one. If we are including a validator, whether sync or async, their validation failures should both propagate errors in a consistent manner. The other possibility might be to provide a decorator argument that allows either:

• raise a validation exception to mirror the behavior of synchronous validation failures
• supply a handler/strategy to allow the user to decide how to handle it

I lean toward consistency with the behavior of synchronous validation. Can you think of a reason why asynchronous validation should behave differently?

[Ananthr16]

Confirmed the root cause with a minimal repro driving the real async retry path (retry_async_v2) directly, bypassing the network:

class Answer(BaseModel):
    email: str

    @async_field_validator("email")
    async def must_contain_at(cls, value: str) -> str:
        if "@" not in value:
            raise ValueError(f"{value!r} is not a valid email address")
        return value

# fake completion always returns {"email": "not-an-email"}
result = await retry_async_v2(func=fake_openai_create, response_model=Answer, ...)
# -> Answer(email='not-an-email'), validator invoked 0 times

async_field_validator/async_model_validator (instructor/v2/validation/async_validators.py) only setattr metadata onto the function — nothing in retry_async_v2 (instructor/v2/core/retry.py) ever reads ASYNC_VALIDATOR_KEY/ASYNC_MODEL_VALIDATOR_KEY or awaits them. AsyncValidationError is already defined and already in the retryable-error tuple, so the reask path is ready, it's just never triggered.

Re: @wWzZb's question above — I'd go with the "clear error" option too: if a sync client is given a response_model carrying declared async validators, raise immediately rather than silently skipping validation. Silent skips are exactly the kind of thing that's expensive to debug in prod.

I see two earlier attempts (#2537, #2559) that both self-closed as stale rather than being rejected on the merits — #2559 in particular looked functionally close but tripped tests/test_import_lazy_openai.py::test_instructor_class_access_does_not_load_openai (the guarantee that touching validation code shouldn't eagerly import the OpenAI SDK), which is worth designing around up front rather than fixing after the fact.

@wWzZb — are you still planning to pick this up? If not I'd like to take it: wire validator execution into retry_async_v2 after parsing (including nested models), raise AsyncValidationError into the existing reask path on failure, and make the sync path fail loudly instead of silently no-op, while keeping the lazy-import invariant intact. Happy to coordinate if you're mid-flight instead.