Network errors crash page render using Apollo Smart Query & Global error handler

[sgarcia-dev]

Version

v4.0.0-rc.5

Reproduction link

https://github.com/sgarcia-dev/error-apollo-client-nuxt/tree/nuxt-apollo-error-handling

Steps to reproduce

• Clone the project located at https://github.com/sgarcia-dev/error-apollo-client-nuxt/tree/nuxt-apollo-error-handling (notice its the nuxt-apollo-error-handling branch)
• Run npm install
• Run npm run dev
• Go to localhost:<port> (logged to the console, likely localhost:3000)
• Page render crashes with this stack trace on the terminal:

Response not successful: Received status code 400

  at new ApolloError (node_modules/apollo-client/bundle.umd.js:92:26)
  at node_modules/apollo-client/bundle.umd.js:1486:27
  at runMicrotasks (<anonymous>)
  at processTicksAndRejections (node:internal/process/task_queues:94:5)

What is expected ?

That the smart query error handler, or nuxt config error handler, catch the error, and allow the page render to render with a fallback value when network errors happen. Be it that the server is down, or that it responds with a mismatching HTML response that yield the common Unexpected token < in JSON at position 0 error.

What is actually happening?

page render crashes, and we have no way of doing anything with the error beyond logging it to the console using supported Vue apollo error handler, and nuxt apollo global error handler.

Additional comments?

The only way to handle error in a way we can silence it or deal with it at this time, is hooking up afterware to apollo client directly using apollo-link-error like in this branch/file of the repo; https://github.com/sgarcia-dev/error-apollo-client-nuxt/blob/master/apollo/apollo-link-error.js

However, while this works (even though its not documented in the @nuxt/apollo docs), this causes a nuxt hydration issue: The client-side rendered virtual DOM tree is not matching server-rendered content. , which throws a white screen on production mode.

Also, you can find a Stack Overflow in depth question I wrote with the things we tried to silence these errors; https://stackoverflow.com/questions/66029623/how-to-handle-apollo-client-errors-crashing-page-render-in-nuxt

_{This bug report is available on Nuxt community (#c362)}

[sgarcia-dev]

@pi0 , tagging you by recommendation of Debbie O'Brien. Since it appears this issue isn't exclusive to apollo-module, but also happens with modules like HTTP and axios.

[it-sha]

Hi @sgarcia-dev. I have faced a similar problem https://github.com/nuxt-community/apollo-module/issues/381. The only solution that I have found is to use asyncData() with the apollo client. The solution described in the issue above.

But using asyncData looks like a duty hack in the case of vue apollo. The smart query is a much more elegant way to deal with gql.

[sgarcia-dev]

I agree with you @it-sha. We actually were aware of that, and created a test branch that verified that here; https://github.com/sgarcia-dev/error-apollo-client-nuxt/commit/5639bd1d5a1ecef875a37a2416e6a2c6b64cfa01

However, our codebase is large and migrating everything from smart queries to promise API will take a long time, thus I created this issue to see if nuxt-apollo supports a way of handling errors triggered by smart queries.

[munjalpatel]

We are also facing the same issue.

We don't actually need to fetch data on the server-side ( it creates a lot more problems than solves ). Is there a way to simply turn off apollo server-side data fetch?

[munjalpatel]

@sgarcia-dev I am trying to implement your workaround using apollo-link-error. But even that is not working. With that implemented now, I get this error: x.concat is not a function and nuxt still crashes on the client-side.

[sgarcia-dev]

I'm sorry to hear that @munjalpatel. We ended up deciding to move away from Nuxt.js since we were unsatisfied with the lack of documentation and community support for dealing with internal errors like these. In the short term, we decided to simply stop using the nuxt apollo module entirely, since that stops server-side data fetching from happening. And we handled errors using the graphql promise API using catch blocks.

It definitely was more code, but dealing with less abstractions seemed like the quickest solution to us.

[munjalpatel]

Yeah, this is definitely frustrating! For us, we are also now planning to move all our apps to React + Next due to lack of proper community support on Vue + Nuxt.