Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.29%. Comparing base (d5196ed) to head (ce02e80).

@@           Coverage Diff           @@
##             main    #3467   +/-   ##
=======================================
  Coverage   98.29%   98.29%           
=======================================
  Files         328      328           
  Lines       14865    14868    +3     
  Branches     2358     2359    +1     
=======================================
+ Hits        14611    14614    +3     
  Misses        116      116           
  Partials      138      138           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Documentation preview will be available shortly at https://litestar-org.github.io/litestar-docs-preview/3467

I'm not enthusiastic about adding more pydantic specific handling in our core, and wonder if there's not a way we can better manage this type of thing with our plugin architecture.

We have this ExtendedMsgSpecValidationError raised by the pydantic type decoders to communicate to our core error handling that the exception has extra detail that can be included in the error response. I wonder if it would be more generic to have the ExtendedMsgSpecValidationError type accept an original_exception parameter instead of the errors mapping, and let the pydantic plugin register an exception handler that can access the original pydantic exception and add the extra detail to the exception response. This way, other serialization plugins could leverage the same behavior.

I'm not enthusiastic about adding more pydantic specific handling in our core, and wonder if there's not a way we can better manage this type of thing with our plugin architecture.

We have this ExtendedMsgSpecValidationError raised by the pydantic type decoders to communicate to our core error handling that the exception has extra detail that can be included in the error response. I wonder if it would be more generic to have the ExtendedMsgSpecValidationError type accept an original_exception parameter instead of the errors mapping, and let the pydantic plugin register an exception handler that can access the original pydantic exception and add the extra detail to the exception response. This way, other serialization plugins could leverage the same behavior.

This approach feels more accessible. I'll try to implement this.

I'm not enthusiastic about adding more pydantic specific handling in our core, and wonder if there's not a way we can better manage this type of thing with our plugin architecture.

We have this ExtendedMsgSpecValidationError raised by the pydantic type decoders to communicate to our core error handling that the exception has extra detail that can be included in the error response. I wonder if it would be more generic to have the ExtendedMsgSpecValidationError type accept an original_exception parameter instead of the errors mapping, and let the pydantic plugin register an exception handler that can access the original pydantic exception and add the extra detail to the exception response. This way, other serialization plugins could leverage the same behavior.

This approach feels more accessible. I'll try to implement this.

Cool, feel free to share early thoughts and if you have any questions I'll do my best to try and answer them. Perhaps best to do this in another branch in case we hit a dead end and end up back here?