React-apollo: Error disappears on re-renders or after mutation

Created on 23 Aug 2019  ·  10Comments  ·  Source: apollographql/react-apollo

Intended outcome:

When error and loading are NOT truthy, data should exist

Actual outcome:

loading: false,
error: undefined,
networkStatus: 7,
data: {
  // no props from graphql query
}

How to reproduce the issue:

To be honest, I cannot reproduce it using https://github.com/apollographql/react-apollo-error-template

In my application everything works fine until:

  1. There is a component that query data and got 404 error
  2. user sign in (graphql mutation)
  3. application re-renders
  4. 404 query should be triggered again but instead of that something weird happen and state of loading, error, data is corrupted like:
data: {
  called: true
  error: undefined
  fetchMore: ƒ ()
  loading: false
  networkStatus: 7
  refetch: ƒ ()
  startPolling: ƒ ()
  stopPolling: ƒ ()
  subscribeToMore: ƒ ()
  updateQuery: ƒ ()
  variables: {id: "1"}
}

Zrzut ekranu 2019-08-23 o 14 36 34

This problem also appears on 3.0.1.
I will try and create reproducible repo but it's quite challenging.

I suppose that it's related with cache configuration because it looks like:

  1. after successful completely unrelated mutation
  2. it's trying to add "simple object" to cache just with id field which is taken from variables passed to that query
  3. error disappears

Zrzut ekranu 2019-08-23 o 15 35 52

Version

  System:
    OS: macOS 10.14.6
  Binaries:
    Node: 10.16.2 - ~/.nvm/versions/node/v10.16.2/bin/node
    Yarn: 1.17.3 - /usr/local/bin/yarn
    npm: 6.10.3 - ~/.nvm/versions/node/v10.16.2/bin/npm
  Browsers:
    Chrome: 76.0.3809.100
    Firefox: 68.0.2
    Safari: 12.1.2
  npmPackages:
    apollo-cache: ^1.3.2 => 1.3.2
    apollo-cache-inmemory: ^1.1.5 => 1.6.2
    apollo-client: ^2.2.1 => 2.6.3
    apollo-link: ^1.2.6 => 1.2.12
    apollo-link-batch-http: 1.2.12 => 1.2.12
    apollo-link-error: ^1.1.11 => 1.1.11
    apollo-upload-client: ^11.0.0 => 11.0.0
    apollo-utilities: ^1.3.2 => 1.3.2

Most helpful comment

@dylanwulf @arianofaoms I confirm that 3.1.0 fixes the problem in my project.

All 10 comments

I have a reproduction of error disappearing on rerender with v3.0.1: https://codesandbox.io/s/error-disappears-on-rerender-301-wdu8j

@hwillson submitted PRs to fix this (#3339 and #3362), but the problem still occurs for me when I specify onCompleted or onError

There was an existing issue about error disappearing on rerender, but it got closed when those PRs were merged: #3295. I was just about to submit a new issue about this, but I see you got to it first

Update: I've found that the error only disappears on re-render if you are using an inline function for onError or onCompleted. If you define your onError and onCompleted functions outside of the render method, then the problem stops happening.

Also experiencing this using <Mutation> and grapqhl() for a separate query. After the mutation (although before its onComplete handler occurs) the query re-renders but this time without the error (despite not making a new successful request).

This started happening after we upgraded from 2.6.x to 3.0.1.

I created a PR which I believe will fix this issue: #3419

I don't understand :/ . The issue is still present. I tried both useQuery and the Query component. Both result in the Error and Loading states being out of sync with the true values.

It seems that the order at which things happen is the issue but I'm not sure. Here is the result:
image

The second time there is a bad request, the error and loading states appear before the result of the query is outputted. :/ need help over here

apollo-boost: ^0.4.4,
apollo-cache-inmemory: ^1.6.3,
apollo-link-context": ^1.0.18,
apollo-link-rest: ^0.7.3,
react: ^16.8.6,
react-apollo: ^3.0.1,

@arianofaoms The fix for this issue hasn't been released yet

@arianofaoms The fix for this issue hasn't been released yet

Thanks for the reply. Any insights as to when it will be?

@arianofaoms Should be available now. v3.1.0 just released

@dylanwulf @arianofaoms I confirm that 3.1.0 fixes the problem in my project.

@dylanwulf @hwillson @arianofaoms This behaves flaky in 3.1.3.

Was this page helpful?
0 / 5 - 0 ratings