Omit input data from validation errors

[ada-globus]

Additionally, ensure that these errors only produce string descriptions, allowing us to normalize error shapes. Further still, adopt HTTP response status code 422 for errors where input is parsable but in an invalid form.

(n.b., in addition to the previously discussed python-jsonschema error messages, this also addresses error dicts emitted by Pydantic, which also include input data.)

I tried to keep this quite narrow, though given that validation errors appear to be the only source of non-string error descriptions, I took the adjacent opportunity to simplify the base error model at the same time.

Note that one of the example APs ("whattimeisit") returns errors in a completely different format from the classes we provide. As such, I did not address it here. Open to continuing to noodle on the validation error messaging if anyone has ideas for simple, obvious improvements.

I'm considering whether additional tests are warranted as this handling appears to be somewhat under-exercised.

Updating APs to use this release should allow validation errors to appear correctly in Flows event logs, as the error parsing performed by the Globus Python SDK will begin to recognize these error messages once description is a string.

[sirosen]

Seeing this reminds me that I don't like that this repo, which is meant to be a library, is using pydantic. It means we're stuck in the pydantic v1 vs v2 situation which is a whole mess of its own.

One thing we didn't talk about is that the SDK is actually capable of parsing multiple messages from a response, which we introduced as part of the JSON:API support path. But it would require that the errors are reshaped in a rather explicit and specific way. We can circle back on that in the future if we want.

[ada-globus]

One thing we didn't talk about is that the SDK is actually capable of parsing multiple messages from a response, which we introduced as part of the JSON:API support path. But it would require that the errors are reshaped in a rather explicit and specific way. We can circle back on that in the future if we want.

💯

This thought occurred to me, too, while I was making sure I'd gone over all of the potential error shapes. Rather ironically, I think the included example AP that does not use the error functionality provided by this package and instead omits a completely different error shape is much closer to the format we'd want in order to handle multiple messages. If we were to move to something like that, though, we'll want to publish a proper error schema and support both paths temporarily... So hopefully with this change that is now a next adjacent move that's newly available to us? 😄

[ada-globus]

Seeing this reminds me that I don't like that this repo, which is meant to be a library, is using pydantic. It means we're stuck in the pydantic v1 vs v2 situation which is a whole mess of its own.

Also, yes, agree—would prefer to see this move away from a framework and more to a collection of, well... tools. 😉