I'm trying to use the error boundaries in react 16 to catch errors and render a fallback UI. However this seems to cause some issues with react-apollo.
Intended outcome:
When a error occurs in apollo, e.g. network error or graphql error I throw an error from the render method (i.e. when props.data.error is set). The component is wrapped in a error boundary implementing the componenDidCatch. When the error is thrown the error boundary unmounts the graphql component and renders a fallback UI.
At this point I expect the error to be correctly handled and apollo cleans up it's internal state.
Actual outcome:
The error is handled by the error boundary and correctly unmounts the graphql component, however I get an unhandled error from apollo.
ObservableQuery.js:297 Unhandled error GraphQL error: Internal Error Error: GraphQL error: Internal Error
at new ApolloError (webpack:///./~/apollo-client/errors/ApolloError.js?:37:28)
at eval (webpack:///./~/apollo-client/core/QueryManager.js?:281:41)
at eval (webpack:///./~/apollo-client/core/QueryManager.js?:661:17)
at Array.forEach (<anonymous>)
at eval (webpack:///./~/apollo-client/core/QueryManager.js?:660:18)
at Map.forEach (<anonymous>)
at QueryManager.broadcastQueries (webpack:///./~/apollo-client/core/QueryManager.js?:655:22)
at Object.next (webpack:///./~/apollo-client/core/QueryManager.js?:687:31)
at SubscriptionObserver.next (webpack:///./~/apollo-link/~/zen-observable/zen-observable.js?:154:14)
at eval (webpack:///./~/apollo-link-dedup/lib/dedupLink.js?:52:76)```
The error seems to be thrown from here: https://github.com/apollographql/apollo-client/blob/master/packages/apollo-client/src/core/QueryManager.ts#L486
How to reproduce the issue:
Error template to reproduce the error: https://github.com/rickardb/react-apollo-error-template
Version
Some observations:
When a wrapped component is unmounted it will be recycled. When recycling a query it's subscribed to https://github.com/apollographql/react-apollo/blob/master/src/queryRecycler.ts#L58:
public recycle(observableQuery: ObservableQuery<any>): void {
// Stop the query from polling when we recycle. Polling may resume when we
// reuse it and call `setOptions`.
observableQuery.setOptions({
fetchPolicy: 'standby',
pollInterval: 0,
fetchResults: false, // ensure we don't create another observer in AC
});
this.observableQueries.push({
observableQuery,
subscription: observableQuery.subscribe({}),
});
}
Since the component and query in question returned with an error the following precondition of ObservableQuery.onSubscribe https://github.com/apollographql/apollo-client/blob/d4dc034f1a74a177a9187870b96ac6d397064774/packages/apollo-client/src/core/ObservableQuery.ts#L533:
if (observer.error && this.lastError) observer.error(this.lastError);
will blow up and cause the console.error('Unhandled error', error.message, error.stack); _(Unhandled error GraphQL error: Internal Error Error: GraphQL error: Internal Error)_ above – during the subscribe while recycling the query.
This seems like a bug to me.
What are the use cases for recycling failed queries at all? On face value it seems as if it would be better to discard them.
I've created a version of the reproduction repo above that uses react router instead of error boundaries to trigger the same error.
Making it possible to navigate between to routes to trigger the problem.
This issue is really preventing me from being able to use react-apollo. When I get a 401 back it just crashes the client, same goes for any other network error. The stack trace always leads back to the above.
Is there any progress being made on this? There's a few issues related to this same problem but all seem stale.
Any progress on this?
This bug still exists. I'm using "react-apollo": "^2.4.0",
the problem still exists.
After some testing on my end it appears that the latest versions of react-apollo and apollo-client solve this issue. If anyone is still having trouble, please reply and I will gladly re-open this thread. Thanks!
Most helpful comment
This issue is really preventing me from being able to use
react-apollo. When I get a 401 back it just crashes the client, same goes for any other network error. The stack trace always leads back to the above.Is there any progress being made on this? There's a few issues related to this same problem but all seem stale.