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.

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

fix: unify server error response across interceptors #555

Merged
merged 2 commits into from
Apr 17, 2024

Conversation

kettanaito
Copy link
Member

@kettanaito kettanaito commented Apr 17, 2024

  • If you throw a Response instance in a request listener, that instance will be used as a mocked response.
  • If you throw anything else, it will be coerced to a 500 error response, similar to how an actual server would handle an uncaught exception.

If you want to emulate a request error, do request.respondWith(Response.error()).

@kettanaito kettanaito requested a review from mikicho April 17, 2024 13:06
@kettanaito
Copy link
Member Author

Hi, @mikicho 👋 If you have a minute, can I ask for your opinion on this?

This is a bit related to handling response stream errors. I'd like to hear your thoughts on this exception handling and if it makes sense to you. Thanks!

if (resolverResult.error instanceof Error) {
// Treat unhandled exceptions in the "request" listener
// as 500 server errors.
xhrRequestController.respondWith(
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The argument of treating exceptions as 500 responses is good, see: #516. TL;DR, if exceptions are preserved, they will be handled by the higher request client. Not only different clients handle those exceptions differently, but that harms the observability of the thrown error.

I also think that treating unhandled exceptions as 500 responses is more similar to the actual server, and you write these request listeners from the server's respective.

*/
// xhrRequestController.errorWith(resolverResult.error)
// Otherwise, error the request with the thrown data.
xhrRequestController.errorWith(resolverResult.error)
Copy link
Member Author

@kettanaito kettanaito Apr 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The argument for translating any other (non-error) data to request errors is a bit weaker. There should be a way to trigger request errors.

Now that I think about it, we do have that way! It's this:

request.respondWith(Response.error())

This translates to a request error across different clients. I think we need to remove non-error handling changes and treat non-errors as 500 responses anyway.

So the three cases become this:

  • Throw a Response, it gets used as a mocked response.
  • Respond with Response.error(), it gets used as a request error.
  • Throw anything unhandled, it gets coerces to a 500 error response.

I think this makes the most sense.

@kettanaito
Copy link
Member Author

This is what I eventually ended up with. I think it makes the most sense and makes the exception handling predictable.

@kettanaito kettanaito force-pushed the fix/non-errors-request-errors branch from 34c3dea to c46fd4d Compare April 17, 2024 13:37
@kettanaito kettanaito changed the title fix: treat thrown non-errors as request errors fix: unify server error response across interceptors Apr 17, 2024
@kettanaito kettanaito merged commit bd0a7dd into main Apr 17, 2024
2 checks passed
@kettanaito kettanaito deleted the fix/non-errors-request-errors branch April 17, 2024 16:20
@mikicho
Copy link
Contributor

mikicho commented Apr 17, 2024

This is great!
More context from discussion in Nock: nock/nock#2211

@kettanaito
Copy link
Member Author

Released: v0.28.3 🎉

This has been released in v0.28.3!

Make sure to always update to the latest version (npm i @mswjs/interceptors@latest) to get the newest features and bug fixes.


Predictable release automation by @ossjs/release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants