Implement fail-fast feature

[uriyyo]

Change Summary

Implement fail-fast feature

Related issue number

pydantic/pydantic-core#1322

Checklist

• The pull request title is a good summary of the changes - it will be used in the changelog
• Unit tests for the changes exist
• Tests pass on CI
• Documentation reflects the changes where applicable
• My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers

Selected Reviewer: @tiangolo

[uriyyo]

please review

[codspeed-hq]

CodSpeed Performance Report

Merging #9708 will not alter performance

_{Comparing uriyyo:fail-fast (64f7267) with main (5694da3)}

Summary

✅ 13 untouched benchmarks

[sydney-runkle]

@uriyyo,

Looking great overall - I've added a few comments / change requests. Let me know when you'd like another review 🚀 !

[sydney-runkle]

Super excited to include this in v2.8 - it'll be a great addition to our performance tips docs as well :).

[uriyyo]

@sydney-runkle Could you please review this PR again? Especially apply_known_metadata changes, not sure it was done correctly.

[sydney-runkle]

Looks great - just a few more changes!

I'll also pull this down locally to do some testing after this next round to make sure things are ready to move ahead!

We can do a pydantic-core minor release next week to prep for v2.8, then get this across the line!

[sydney-runkle]

Same question - is fail_fast applicable to all sequence types? It probably should be for this case, but the case about where we reuse SEQUENCE_CONSTRAINTS is where more of my concern lies.

[sydney-runkle]

Also, let's add some tests for my_field: Sequence = Field(..., fail_fast=True), etc.

[sydney-runkle]

Then see what happens with a deque or something like that

[uriyyo]

Same question - is fail_fast applicable to all sequence types?

You are right, it's not applicable to all sequence types. But I don't know how to correctly pass fail_fast to schema. Before calling apply_known_metadata it' always calls sequence_like_prepare_pydantic_annotations that fails because fail_fast is not in a list of SEQUENCE_CONSTRAINTS.

Maybe you have PR example how to correctly implement staff like this?

[uriyyo]

Also, let's add some tests for my_field: Sequence = Field(..., fail_fast=True), etc.

It won't work for now. I guess first we need to implement a way how from python say rust to stop validation.

More context here - pydantic/pydantic-core#1322 (comment)

[uriyyo]

please review

[sydney-runkle]

Awesome work here!

Approved. We'll merge this in once we get the next pydantic-core version released. Should be later this week 🚀

[Viicos]

I'm really liking this feature. I'm guessing we could have something similar at the model level:

from pydantic import BaseModel, ConfigDict, ValidationError

class Model(BaseModel):
    a: int
    b: int

    model_config = ConfigDict(fail_fast=True)

try:
    Model(a="some", b="string")
except ValidationError as e:
    print(e)
    # Only one error, for a

# or:

try:
    Model.model_validate({"a": "some", "b": "string"}, fail_fast=True)
except ValidationError as e:
    ...

---

Other than that, I'm hoping this is forward compatible with what was suggested here (making it an exception), then it could also be extended to any type:

from typing import Annotated

from pydantic import BaseModel, BeforeValidator

def my_validator(value: Any):
    raise FailFast  # Or `FailNow`?

class Model(BaseModel):
    a: Annotated[int, BeforeValidator(my_validator)]
    b: int

# Validating `Model` would not do the validation for `b`.

[sydney-runkle]

Agreed, this is super promising as a new pattern.

Issues / PRs welcome re the ideas suggested above by @Viicos 🚀