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

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

Closed
1 task done
jerelmiller opened this issue Mar 4, 2024 · 2 comments · Fixed by #795
Closed
1 task done

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

jerelmiller opened this issue Mar 4, 2024 · 2 comments · Fixed by #795

Comments

@jerelmiller
Copy link
Contributor

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?
@pi0
Copy link
Member

pi0 commented Jun 19, 2024

Hi dear @jerelmiller sorry for late reply.

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?

This sound a good idea if cause.statusCode is available this way also h3 does not needs to add framework specific logic.

@jerelmiller
Copy link
Contributor Author

Hey @pi0 no problem! Thanks for the reply!

Glad to hear this idea is on the right track! I've got some priorities I need to get to this week, but I'm hoping I can contribute a PR for this in h3 sometime soon.

@phryneas opened apollographql/apollo-client#11902 on our end which we are hoping to land in the next patch or two. I look forward to moving this forward!

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

Successfully merging a pull request may close this issue.

2 participants