Fix field validation on Base64Bytes and Base64Str

[LouisGobert]

Change Summary

Fix field validation on Base64Bytes and Base64Str.

Related issue number

fix #9251

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: @Kludex

[LouisGobert]

please review

[codspeed-hq]

CodSpeed Performance Report

Merging #9263 will not alter performance

_{Comparing LouisGobert:fix-field-option-on-base64 (d3795cf) with main (ae71183)}

Summary

✅ 13 untouched benchmarks

[ybressler]

Left some informationally driven Q's for you.

[ybressler]

Why is it necessary to remove the type from the base schema?

[sydney-runkle]

Great question!

[ybressler]

Wouldn't _convert_schema be more appropriate here, instead of unpacking and recreating, perform the union?

[ybressler]

Consider adding a test for non url safe base64 encoding too

[sydney-runkle]

@ybressler left some good questions / feedback here.

I'd be inclined to think that this might have more to do with applying known metadata - you might be able to get a cleaner fix there (just a hunch, haven't confirmed).

[LouisGobert]

@sydney-runkle @ybressler Hy,

I removed the type because it should always be bytes, otherwise the data (Base6Str) won't be converted to bytes before decoding, thus raising an error.

I'm not sure if the best solution is to use a different encoder for the EncodedStr class (which avoids the conversion to bytes) or another approach. By forcing the value into bytes in my current solution (by removing the type, as the type comes from the core_schema because otherwise a TypeError is raised since the bytes_schema function does not have a type argument (coming from the unpack)), we ensure that the data must and will be converted to bytes in the first place.

[ybressler]

Thanks for sharing your thought process. It sounds like existing encoder is not correct - that we should be using a diff encoder, is that right? If this is the case, why not make a new class and manipulate the properties there? This will create a much more extendable solution.

[LouisGobert]

@ybressler Yes, that's a good idea. But, the problem will still persist.

Here's my analysis:

To have the complete metadata (min, max length, ...), we must necessarily call the handler(source) function from the EncodedBytes.__get_pydantic_core_schema__ function. If we just use core_schema.bytes_schema(), the information will not be complete (as it is currently the case).
However, if we call handler(source) alone, the type may not match the actual type of the expected field. There will be no conversion to this expected type, thus leading to errors.

For example, using just schema=handler(source) in EncodedBytes.__get_pydantic_core_schema__ and running the example test from the docstring:

MyEncodedStr = Annotated[bytes, EncodedStr(encoder=MyEncoder)]

class Model(BaseModel):
    my_encoded_str: MyEncodedStr

>> Value error, Cannot decode data [type=value_error, input_value='**undecodable**', input_type=str]

this will use a type="str" from source instead of bytes.

[sydney-runkle]

@LouisGobert,

Hmph, if the encoder is behaving incorrectly, perhaps we need to pivot to fixing the bug in pydantic-core?

Edit: perhaps I misunderstood, after taking a closer look. I'll consult with the team about this issue regarding where a fix would make the most sense.