Peter Schutt

Looks like there are some more recent deprecation's are surfacing from https://github.com/pydantic/pydantic-core/pull/980. E.g.,: ``` /beanie/odm/fields.py:554: DeprecationWarning: `general_plain_validator_function` is deprecated, use `with_info_plain_validator_function` instead. return core_schema.general_plain_validator_function(validate) ```

No worries @afonasev - this is something I'd be interested in looking at but my available bandwidth is also very low. If I do pick it up I'll ping you...

Litestar's DTOs ([tutorial](https://docs.litestar.dev/latest/tutorials/dto-tutorial/index.html), [docs](https://docs.litestar.dev/latest/usage/dto/index.html)) are doing something akin to this. We take some annotated type that is used for domain modelling (e.g., dataclass, sqlalchemy model, struct, pydantic model etc) and...

This would also allow Litestar to customize our client errors with less work (i.e., not having to rely on regex to parse the error message). This wouldn't require any more...

> One thing, I wanted to add which I only realized now is that I think the way that `msgspec` does validation, it'll stop immediately when the first invalid input...

> Apologies for the delayed response here, I'm currently out on parental leave. No probs whatsoever! Thanks for the explanation of the interplay between `Struct` and `type`, that's really helpful....

No, just ran into a dead-end with the approach I was taking and have been sidetracked since.

> What do people think? No objection from me. My question is whether we should consider it a breaking change and whether we should feature-flag it somehow.

> I don't think this would break any existing user code since emitters are relatively new (added in v2 in August), context vars are not used that commonly, and IMO...

> @peterschutt Sounds like this can't be merged because it's breaking? I like the idea of being able to correlate things done by listeners to the requests that caused them....