swift-openapi-generator: Handle encoding and decoding errors in a middleware-like extension point

Question

I’d like to add telemetry to my app to report issues where an API response is missing a required key or otherwise has decoding errors. Ideally I could write middleware to achieve this, but from what I’ve been able to tell, middleware can’t intercept decoding errors.

In a perfect world, the server handling the API requests would always return 100% spec-compliant responses, never introducing breaking changes, but mistakes happen.

How would you suggest I add this telemetry to my client application using swift-openapi-*?

About this issue

Original URL
State: open
Created 5 months ago
Comments: 15

Commits related to this issue

Add a hook for intercepting decoding errors This is just a proof-of-concept, if this direction is reasonable, it should be fleshed out to handle all decoding paths. See https://github.com/apple/swif... — committed to jpsim/swift-openapi-runtime by jpsim 5 months ago

Most upvoted comments

If it’s just instrumentation that users are after, should we consider adding “actual” instrumentation to the runtime library, i.e. by depending on Swift Metrics and emitting metrics for these sorts of things with dimensions for the operationID and the kind of error?

Comprehensive metrics would be great, but much broader scope compared to my near-term needs
Ideally comprehensive metrics would be pluggable like ClientTransport currently is to: a. avoid the cost of the swift-metrics dependency for users who don’t need it b. allow for alternative metrics implementations

Also I consider fine-grained metrics (number of requests, failure #s, timing data histograms, etc) to be fairly distinct from and very differently actionable compared to decoding errors where a server is returning non-conformant responses. So I can see some benefit in having a unified metrics solution but that’s not necessary for this level of instrumentation.

jpsim on Feb 5, 2024

These are no doubt important questions for you to answer as a library author. From my perspective, any answer to those questions would satisfy my need to add instrumentation and alerting to api response decoding errors.

jpsim on Feb 4, 2024

Yes, I can catch decoding errors at the call site like this, but that will lead to a lot of duplication.

This seems like a perfect fit for middleware conceptually, where other metrics and instrumentation can easily be added for all endpoints without needing the call sites to explicitly handle those cases.

Consider this a feature request to consider having centralized handling of decoding errors 🙏

And thanks for all your efforts in making this library ❤️

jpsim on Feb 3, 2024