Error Observable cancelled prematurely get's thrown #7608
Comments
|
I am experiencing same issue. This had started with version Apollo Client 3.3.0. For now I had downgraded to Apollo Client 3.2.9. . I think that this issue is connected with this feature "Unsubscribing the last observer from an ObservableQuery will once again unsubscribe from the underlying network Observable in all cases, as in Apollo Client 2.x, allowing network requests to be cancelled by unsubscribing." Witch was implemented in Apollo Client 3.3.0 |
|
Having the same issue here. With me, it also seems to happen when the provider gets unmountend and mounted again. |
|
Experiencing the same thing in an Angular project, when navigating away from a page where a query is happening. |
|
We're having the same issue on v.3.3.9. Reverting to 3.2.9 is not an option, because it starts throwing Invariant Violations. Any insight on how to fix this? I can confirm that the Apollo Client Provider is being mounted only ONCE and never re-mounted. |
|
Thanks @capaj for posting your workaround, very useful. To the Apollo folks, it seems to me like throwing an error and breaking the user's app is a bit extreme for this type of issue (especially since it appear to only occur in production mode). I have no knowledge of this codebase, but could this line not pass |
|
We are also facing this issue in our React app |
|
I was having this problem, I read and research several things about that issue. Unfortunately, the issue is specific to your approach and codebase. You may have a memory leak or unexpected behavior on your product as a code. Already it proofs that because all these comments are pointing to different complaints. |
|
This definitely looks like a problem on our end and I apologize for all the grief it’s caused. I currently have a lot on my plate, but I will make sure to look at this soon. In the meantime, if anyone created a smallish reproduction using our error template (https://github.com/apollographql/react-apollo-error-template), that would probably magically move this issue up in my TODOs 😇 |
|
It seems I only get this error if |
|
Somewhat of a repro, with angular. |
|
This started for me when i used a hook together with a LazyQuery that refetches in a useEffect. const { someIds } = useSomeHook();
const [getItems, { loading, data }] = useItemsLazyQuery();
React.useEffect(() => {
getItems({
variables: {
ids: someIds,
},
});
}, [someIds]);if i remove the code from the hook, and move the logic next to the query, it will work fine! |
|
For us, it happens when you unmount and remount the sasme component really fast. |
|
Any progress? This issue is a huge problem for me. |
|
We're seeing this issue in production as well. |
|
Switching the |
|
I am seeing this when using react-router Using capaj's workaround fixes the issue for now, but it's not an idea UX. |
|
If it helps, I started getting this error after updating |
|
I noticed this starting to happen in my Angular app. It generally happens on sign in. You immediately get booted out of the app and it throws the "Observable cancelled prematurely" message. Unfortunately, we cannot reproduce with certainty so it's been a nightmare to try and replicate, much less fix. |
|
We are seeing this as well and happens typically during a storm of queries for the same data with cache-first (should resolve to cache). Maybe that helps getting an idea for some repro. Here same thing sometimes works, sometimes not :-/ |
Inspired by @cornedor's comment: #7608 (comment) Should help with some instances of issue #7608, specifically those with global unhandled promise rejection errors. I don't know if this is the full solution, but I believe it is helpful and safe to introduce a delay before unsubscribing, giving other subscribers a chance to subscribe, thereby saving the Concast from needing to be cancelled.
|
@cornedor (and @matthewrc) I actually think the Partial(?) fix incoming: #8676 |
|
In our case the issue was that we had two components rendering at the same time and starting the same subscription. While that was happening, one of them used to unmount due to history.replace in a matching condition. That was causing "observable cancelled prematurely". |
|
Adding to what people wrote here. We hit this issue with regular queries (not a subscription) and only when developing locally (with Downgrading to 3.2.9 like the rest solved the issue. |
|
Is there any update to this? This behavior with regards to quick mounts/unmounts seems to be breaking with React 18. |
|
I receive this error in usual query when I set {fetchPolicy: 'cache-and-network'}, when I replace it to {fetchPolicy: 'network'} error disappeared |
|
I'm cautiously optimistic this problem may be solved once and for all by #9701, which you can test by running npm i @apollo/client@betato get version |
benjamn
added
🏓 awaiting-contributor-response
|
@benjamn I already go the change to try it out, thanks a lot for the effort! I am still getting an error when using the Below is the error that is logged in the dev console in the browser. Here you can see the corresponding
Screenshot of messages when subscription is workingWhen disabling `StricteMode` the , the `messages` look like this:
|
|
|
Can also confirm that |
benjamn
removed
the
🏓 awaiting-contributor-response
This is likely due to the additional time it takes to do the network side of the fetch |
|
We believe this is now resolved in |
Well, the warning and error logged is fixed. But the problem is that the application doesn't subscribe at all. |
|
@benjamn Thanks for your work, but the problem is still not solved, and it's worse in the new versions, because before you could at least see the error and know that something was wrong, but now not even that. Could you re-add the error message? I have a temporary fix using the error |
|
@myth535 I have the same problem, the useSubscription sometimes works and sometimes don't, feels unstable. The subscription feels more stable and works well! |
and others
Sorry that I cannot provide more info.
I may get some time to try and reproduce this in codesandbox in the future, but for now I just wanted to have a linkable bug reference to put into our codebase.
For now we have this hackfix in ErrorBoundary component to get around this:
Intended outcome:
no error is thrown no matter how we mount/dismount providers.
If this indeed happens when a provider is unmounted by react then it should be caught by apollo-client because at that point we really don't care about these observables and their values at all.
Actual outcome:
this error is thrown:
How to reproduce the issue:
I actually don't know.
This error is thrown on startup of our closed source app, so I cannot share the code.
The app actually has 2 graphQL endpoints and we switch between them depending on the route where the user is and I think this error get's thrown when one apollo provider is unmounted, but I cannot be sure.
Versions
The text was updated successfully, but these errors were encountered: