Ensure ValidationInfo.field_name is correct on validator reuse

[DouweM]

Change Summary

See pydantic/pydantic#11737 (comment)

Related issue number

Fixes pydantic/pydantic#11737

Checklist

• Unit tests for the changes exist
• Documentation reflects the changes where applicable
• Pydantic tests pass with this pydantic-core (except for expected changes)
• My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers

Selected Reviewer: @sydney-runkle

[DouweM]

@davidhewitt Please review!

cc @Viicos

Edit: Never mind, failing tests, looking

[codspeed-hq]

CodSpeed Performance Report

Merging #1692 will not alter performance

_{Comparing DouweM:validator-reuse-field-name (9bac3bd) with main (9a25aa6)}

Summary

✅ 157 untouched benchmarks

[DouweM]

I ended up changing some tests in 0fd7ef1 and df34451.

Both are similar to the issue described in pydantic/pydantic#11737 (comment): we now get ValidationInfo.field_name even if the validator wasn't explicitly created for a specific field, which is not always expected.

I think the changes in the second commit make sense as the validator acts on the field value, but not necessarily in first commit where the validator acts on the entire model.

I'm not sure the State based approach gives us the ability to drop the field_name in that specific case though. I think I'm OK with this change in behavior, interpreting field_name as "this is the field currently being validated" more than "this is the field the validator acts on".

@Viicos What do you thnk?

[DouweM]

We're hitting some leak/GC issues! https://github.com/pydantic/pydantic-core/actions/runs/14476861875/job/40604489000?pr=1692

[davidhewitt]

Thanks, looking good!

[davidhewitt]

We're hitting some leak/GC issues! https://github.com/pydantic/pydantic-core/actions/runs/14476861875/job/40604489000?pr=1692

These might be reproducable on main; it's possible it's something new with 3.13.3.

[davidhewitt]

LGTM, with just the question of maybe we start cleaning up the existing state to keep things efficient.

The 3.13t tests will not block merge, so depending on whether we leave the above for a follow-up this is good to go 👍

[Viicos]

LGTM, with just the question of maybe we start cleaning up the existing state to keep things efficient.

You mean having the state rebound only if we are certain a validator (with info) is going to be used?

[davidhewitt]

LGTM, with just the question of maybe we start cleaning up the existing state to keep things efficient.

You mean having the state rebound only if we are certain a validator (with info) is going to be used?

Nope I just meant the deprecation which you agreed with. 👍

[DouweM]

I think this TypedDict is only used for type hinting -- let me know if this is sufficient or if we should force a deprecation warning here as well somehow.

[DouweM]

This test explicitly tested the now-deprecated behavior of setting a field_name on the validator function schema. If we assume no one was directly constructing these instead of us, removing this should be fine.

I could also leave the test and wrap the call in pytest.warns, to verify the old behavior keeps working (which it does) -- let me know what you prefer.

[DouweM]

@Viicos Pydantic is still passing field_name, so it makes sense that test-pydantic-integration is failing now that I've deprecated it.

What's the best way to update pydantic for the new pydantic-core, before this is even merged?