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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow for parsing of error status codes from non-http response errors. #691

Open
1 task done
jerelmiller opened this issue Mar 4, 2024 · 0 comments
Open
1 task done

Comments

@jerelmiller
Copy link

Describe the feature

Hey there 馃憢

I'm an Apollo Client maintainer. I'd like to start a discussion in regards to error handling when using Apollo Client with Nuxt/h3 and see if we can collaborate on a solution.

We recently had this issue opened in our repo noting that network errors thrown by Apollo Client aren't forwarding the status code to h3's underlying H3Error due to how the status code is parsed in h3's error creation functions. It appears createError expects a statusCode property in order to set this on the H3Error instance. Unfortunately this doesn't integrate well with Apollo Client because Apollo Client wraps all errors in its own ApolloError instance. The status code is lost since the status code is instead found in error.networkError.statusCode.

I'd love to contribute a way to allow for these libraries to work better together. Unfortunately we are stuck with this error structure for the foreseeable future and we'd like to avoid adding a statusCode property to ApolloError itself, especially since Apollo Client's core aims to be framework agnostic.

One potential solution is that we could add a cause from ApolloError to the original error. With this perhaps createError could try to parse status/statusCode from error.cause if its available?

I'd love to get your thoughts on this! At the very least, perhaps a recommendation I could take back to the original issue would be useful. I'll be honest, I'm pretty unfamiliar with Nuxt/h3, so any help would be appreciated. Thanks!

Additional information

  • Would you be willing to help implement this feature?
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

No branches or pull requests

1 participant