This rule raises an issue when a schema type specification parameter is used in a field validation decorator configured to run after type conversion, or when the validation timing is not explicitly specified (which defaults to running after conversion).

In Python/Pydantic, this specifically refers to using the json_schema_input_type parameter in a @field_validator decorator.

Why is this an issue?

Using an input type schema parameter with an incompatible validation mode will cause the framework to raise a user error when your model is defined, preventing your application from starting.

In Pydantic specifically, this refers to the @field_validator decorator with its json_schema_input_type parameter. Using json_schema_input_type with mode='after' will cause Pydantic to raise a PydanticUserError when your model is defined. There is no valid use of json_schema_input_type with mode='after'; this combination always fails at class definition time.

What is the potential impact?

This issue will cause an immediate runtime error when the affected class or type is defined. The application will fail to start, making it impossible to use any functionality that depends on the affected type definition.

This is a critical bug that will be discovered as soon as the code path defining the type is executed, typically during application startup or when the relevant code unit is first loaded.

How to fix it

If you need to specify json_schema_input_type, change the validator mode to before, plain, or wrap:

• mode='before' is typically the best choice. The validator runs before Pydantic’s type conversion, so json_schema_input_type correctly describes the raw input type the schema should expect.
• mode='plain' replaces Pydantic’s built-in validation entirely. Use it when the validator handles all type checking itself and Pydantic’s standard conversion should not run.
• mode='wrap' gives the validator control over when Pydantic’s built-in validation runs by receiving a handler argument. Use it when you need to inspect or modify the value both before and after Pydantic’s conversion.

Code examples

Noncompliant code example

from pydantic import BaseModel, field_validator

class Model(BaseModel):
    a: str

    @field_validator('a', mode='after', json_schema_input_type=str)  # Noncompliant
    @classmethod
    def validate_a(cls, v):
        return v

Compliant solution

from pydantic import BaseModel, field_validator

class Model(BaseModel):
    a: str

    @field_validator('a', mode='before', json_schema_input_type=str)
    @classmethod
    def validate_a(cls, v):
        return v

Pitfalls

When switching to mode='wrap', the validator function must accept a second handler argument in addition to the value. Using the standard (cls, v) signature with mode='wrap' causes a separate PydanticUserError about an unrecognized function signature.

from pydantic import BaseModel, field_validator

class Model(BaseModel):
    a: str

    # mode='wrap' requires (cls, v, handler), not (cls, v)
    @field_validator('a', mode='wrap', json_schema_input_type=str)
    @classmethod
    def validate_a(cls, v, handler):
        return handler(v)

Resources

Documentation

• Pydantic Documentation - Field Validators
• Pydantic Documentation - field_validator API reference