Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Attach more context information to errors thrown in middlewares #17

Closed
czechboy0 opened this issue May 25, 2023 · 0 comments
Closed

Attach more context information to errors thrown in middlewares #17

czechboy0 opened this issue May 25, 2023 · 0 comments
Labels
area/runtime Affects: the runtime library. kind/enhancement Improvements to existing feature. size/S Small task. (A couple of hours of work.)
Milestone
Post-1.0

Comments

@czechboy0
Copy link
Contributor

Currently, when errors are thrown in a transport, we attach as much context as we have at that point (the Input value, operationId, etc). But when an error is thrown in a middleware, we don't attach some info that we could, so let's fix that. Will make debugging errors thrown by middlewares quicker, if all the right context is already attached and logged.
@czechboy0 czechboy0 added area/runtime Affects: the runtime library. kind/enhancement Improvements to existing feature. size/S Small task. (A couple of hours of work.) labels May 25, 2023
@czechboy0 czechboy0 changed the title Attach latest response value to errors thrown in middlewares Attach more context information to errors thrown in middlewares May 25, 2023
@czechboy0 czechboy0 added this to the Post-1.0 milestone Aug 25, 2023
@czechboy0 czechboy0 mentioned this issue Oct 25, 2023
Merged
czechboy0 added a commit to apple/swift-openapi-runtime that referenced this issue Oct 26, 2023
@czechboy0
Improved enriched error propagation from the transport and middlewares (
ad8bf04 
#63)

Improved enriched error propagation from the transport and middlewares

### Motivation

Fixes apple/swift-openapi-generator#302 and apple/swift-openapi-generator#17.

The issue was that we hid away errors thrown in transports and middlewares, and the adopter would get `ClientError` where the `underlyingError` wasn't the error thrown by the underlying transport/middleware, but instead a private wrapper of ours.

### Modifications

Make sure `{Client,Server}Error.underlyingError` contains the error thrown from the underlying transport/middleware when that was the cause of the error, otherwise keep `RuntimeError` there as was the behavior until now.

Also added a `causeDescription` property on both public error types to allow communicating the context for the underlying error.

Also made sure middleware errors are now wrapped in Client/ServerError, they weren't before so didn't contain the context necessary to debug issues well.

### Result

Adopters can now extract the errors thrown e.g. by URLSession from our public error types using the `underlyingError` property and understand the context of where it was thrown by checking the user-facing `causeDescription`.

Also, adopters now get enriched errors thrown from middlewares.

### Test Plan

Wrote unit tests for both UniversalClient and UniversalServer, inevitably found some minor bugs there as well, fixed them all, plus the unit tests now verify the behavior new in this PR.


Reviewed by: glbrntt

Builds:
     ✔︎ pull request validation (5.10) - Build finished. 
     ✔︎ pull request validation (5.8) - Build finished. 
     ✔︎ pull request validation (5.9) - Build finished. 
     ✔︎ pull request validation (docc test) - Build finished. 
     ✔︎ pull request validation (integration test) - Build finished. 
     ✔︎ pull request validation (nightly) - Build finished. 
     ✔︎ pull request validation (soundness) - Build finished. 
     ✖︎ pull request validation (api breakage) - Build finished. 

#63
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area/runtime Affects: the runtime library. kind/enhancement Improvements to existing feature. size/S Small task. (A couple of hours of work.)
Projects
None yet
Milestone
Post-1.0
Development

No branches or pull requests
1 participant
@czechboy0