Intended outcome:
I would expect the onCompleted
callback to be fired after every poll.
Actual outcome:
onCompleted
is being fired only once. First time the query is made.
How to reproduce the issue:
const { data, stopPolling } = useQuery(QUERY, {
variables: {...},
fetchPolicy: 'network-only',
pollInterval: 1000,
onCompleted: () => console.log('called')
})
Versions
npmPackages:
@apollo/react-common: ^3.0.1 => 3.0.1
@apollo/react-hooks: ^3.0.1 => 3.0.1
apollo-cache-inmemory: ^1.3.5 => 1.3.11
apollo-client: ^2.6.4 => 2.6.4
apollo-link: ^1.2.3 => 1.2.4
apollo-link-context: ^1.0.10 => 1.0.10
apollo-link-error: ^1.1.1 => 1.1.2
apollo-link-http: ^1.5.5 => 1.5.7
apollo-link-logger: ^1.2.3 => 1.2.3
apollo-server-koa: ^2.1.0 => 2.2.4
apollo-utilities: ^1.3.2 => 1.3.2
react-apollo: ^2.2.4 => 2.3.2
Have you checked the network traffic? I believe that it does not actually poll, as opposed to executing onComplete only on the first query.
@ajhool I have just tested it again and I can confirm that the query is being called multiple times. I can see it in the network traffic every second, but the onCompleted
is being called only once.
Yeah i'm seeing the same thing.
"apollo-cache": "^1.3.2",
"apollo-cache-inmemory": "^1.6.3",
"apollo-client": "^2.6.4",
"apollo-link": "^1.0.6",
"apollo-link-error": "^1.0.3",
"apollo-link-http": "^1.3.1",
"graphql-tag": "^2.4.2",
"ts-invariant": "^0.4.0",
"tslib": "^1.9.3"
+1 Having same problem here. onCompleted will be fired only once at the first fetch.
+1 Im also seeing the same issue
Setting notifyOnNetworkStatusChange
to true
solved the issue in my case.
This could be the culprit?
It seems onCompleted only runs when data has changed, so if you are polling and no data changes occur then it will not fire.
Ideally there could be an extra prop to always call. Or maybe an alternative function prop, onCompletedAlways
?
A workaround for our case was to add fetchPolicy: 'no-cache',
to the query options. Thus:
const { data, stopPolling } = useQuery(QUERY, {
variables: {...},
fetchPolicy: 'network-only',
pollInterval: 1000,
onCompleted: () => console.log('called'),
fetchPolicy: 'no-cache',
})
Obviously this means you will bypass the client-side cache but it will ensure the completion hook is triggered every time.
We've tried the workarounds here but none work.
We don't see onCompleted
firing at all with @apollo/client 3.0.0-beta.37.
Even the first call to the query doesn't print to the console.
const messagesQuery = useQuery(GET_CHAT_MESSAGES_BY_GROUP_ID, {
variables: { chatGroupId },
pollInterval: 1000,
onCompleted: () => console.log('If this worked no useEffect needed. 馃槙'),
});
I'm running into this issue as well. Even with fetchPolicy: 'no-cache'
the onCompleted
handler is only being called once.
The same is true for onError
. It's called for the first error but is not called if later poll attempts have errors. The workarounds do not help me.
Can confirm as well
Same behaviour here
Guys, set the fetchPolicy: 'network-only', it should work then, I had the same problem. And better switch to: useLazyQuery instead of polling if it is possible.
Guys, set the fetchPolicy: 'network-only', it should work then, I had the same problem. And better switch to: useLazyQuery instead of polling if it is possible.
Erm sorry but that's subjective. I need to store it in the cache since it's very expensive for me to re-fetch it. I need polling since I'm using it for an async server operation that has the results ready in between 30secs and 2 minutes, thus I need to continuously "check" if they are ready for serving
Also, @dominik-myszkowski , setting fetchPolicy: 'network-only'
only triggers the onCompleted
once. I can only get it working by setting notifyOnNetworkStatusChange: true
This could be the culprit?
It seems onCompleted only runs when data has changed, so if you are polling and no data changes occur then it will not fire.
Ideally there could be an extra prop to always call. Or maybe an alternative function prop,
onCompletedAlways
?
Are any of you falling in to this conditional? Is it not firing when no data has changed?
@bhishp I would really love the onCompeted event only to run on data changed. however even when the data changes, I cannot see the onCompeted method triggered
Setting
notifyOnNetworkStatusChange
totrue
solved the issue in my case.
This worked for me. Setting 'network-only' did not.
@hwillson any updates on that with the release of 3.0?
@andreasonny83 I'm seeing the same, the data changed but my onComplete didn't fire. notifyOnNetworkStatusChange
fixed the issue for me. Still happening even in version 3.1.0-pre.1
The issue with setting notifyOnNetworkStatusChange
is that it will rerender for every poll interval (as documented). This is probably not what you want and you'd want to rerender only when the data changes.
@jure Yes, but as @andreasonny83 mentioned and I've also confirmed, it isn't firing when the data changes.
Right, absolutely, it should! That's the bug. I've commented merely to point out that setting notifyOnNetworkStatusChange
isn't a workable workaround in many situations and that folks should be aware of that drawback before applying it willy nilly, as it causes the whole tree below the hook to rerender on every interval.
For what it's worth, I've sort of resolved the issue caused by this workaround for the time being by chucking the polling useQuery
into a dead end of the tree, so the rerendering isn't annoying. In there I then use makeVar
which is then used in the typePolicies
of the InMemoryCache, like this:
{
cache: new InMemoryCache({
typePolicies: {
Manuscript: {
fields: {
_currentRoles: {
read(existing, { cache, args, readField }) {
const currentRoles = currentRolesVar()
},
},
},
},
},
}
It's quite the detour, but it works, so hopefully it's useful for someone else too.
Yup, can confirm. Still happening in 3.3.6
. I resolved the issue with notifyOnNetworkStatusChange
, though it's like using a baseball bat to clean the dishes.
The only other alternative I can come up with is using a useEffect
, and refetch
.
Most helpful comment
Setting
notifyOnNetworkStatusChange
totrue
solved the issue in my case.