Apollo-client: Catch error on watchQuery poll

[fischerman]

I posted this issue on SO, but no response, so I post it here as a potential bug report.
https://stackoverflow.com/questions/44898988/apollo-client-how-to-catch-error-with-pollinterval

I have a watchQuery with a pollInterval, like so:

apollo.watchQuery<any>({
  query: ...,
  pollInterval: 10000
}))/** retry logic omitted **/.subscribe(..., (err) =>  {console.error(err)})

I want to ignore any network errors for this particular query.

Intended outcome:

Catch all errors during a poll using the Observable error handler. Network related errors should only bubble up where the query is initiated (including later polls).

Actual outcome:

The error handler is called but I get an additional uncaught promise rejection:

How to reproduce the issue:

• Create a watchQuery with a poll interval, set an error handler on the subscribe call
• Simulate network error (e.g. chrome dev bar)

Additional Info

QueryManager.js:235 maps to QueryManager.ts:476

[email protected]

[jbaxleyiii]

@fischerman thank you for the bug report! Would you be able to create a reproduction repo or even better, a failing test?

I suspect the error is coming from here

[fischerman]

@jbaxleyiii I've created a reproduction repo here. It's an angular-cli project.

I have also created a test case, however that runs through without errors: https://github.com/apollographql/apollo-client/compare/master...fischerman:issue/1881?expand=1
I would have expected to see errors in the console. I'm not sure how asynchronous errors are handled in the testing framework. Can you have a look?

[fischerman]

@jbaxleyiii do you need more information at this point?

[jbaxleyiii]

@fischerman sorry I haven't taken a look yet! I'll be out of town this week but will add it to my list first of next week!

[stale[bot]]

This issue has been automatically marked as stale becuase it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions to Apollo Client!

[stale[bot]]

This issue has been automatically closed because it has not had recent activity after being marked as stale. If you belive this issue is still a problem or should be reopened, please reopen it! Thank you for your contributions to Apollo Client!

[KillerCodeMonkey]

@jbaxleyiii I've got the same error.

1. created a watchQuery with pollInterval
2. if an network error occurs (using https://github.com/mstn/apollo-local-network-interface) i get a hard JS Error
3. The error callback of the subscription is called once

So i am sending requests to another server in my resolvers. If i am using polling --> deactivating the network connection the polling fails and i am not able to catch this error.

Seems like the polling is done by apollo the error should be caught there and should be re-thrown to be handled by us.

[KillerCodeMonkey]

@jbaxleyiii seems like this is a general problem with watchQueries.

First the cache is used and then the network request is made. If the network request fails you are not able to catch those errors :(

Any Ideas?

@fischerman do you have a solution?

[fischerman]

@KillerCodeMonkey I have not found a solution, I don't actively work with Apollo anymore.

I think this issue is still unresolved. @jbaxleyiii Can you reopen it, please?

[KillerCodeMonkey]

@fischerman thanks for your quick response.

@jbaxleyiii
Yeah i think with this case it makes the apollo-client more or less useless for me, because in many cases i want to use 'cache-and-network' or even a simple 'cache-first' watchQuery. But if i am not able to handle those errors (which happens when the cache value is returned first and the real request data later - that is failing). Those things can happen often in real life, like the network connection is lost.

[joevandyk]

@jbaxleyiii can this be re-opened?

[hobochild]

I'm also finding an error with this, @jbaxleyiii mind opening this so it can get some more attention again?

[dcosson]

I'm having this issue as well, and it makes watchQuery much more difficult to rely on.

The behavior I would expect to get, or at least this should be a configuration option, is for it to call the next() path on the Observable with any error like a network error or even a graphql error and for the Observable to stay open. There are lots of cases you can imagine that it could succeed again after failing (for example, when it tries again after pollingInterval maybe the network is back up or a fix has been deployed to the server, or maybe some other part of the client code might write the requested data to the cache and trigger the watchQuery to succeed).

Instead, any error seems to trigger the error callback of the Observable which closes it.

@jbaxleyiii is there any way to re-open this issue, for discussion on whether this is a bug or desired behavior and whether a PR that changes this would be accepted?

[michelcve]

It seems like @jbaxleyiii moved to management or something, so maybe that's why there's no follow up on this one?

Can you perhaps take a look at this @danilobuerger, and reopen it? It would be really great if this could be resolved.

[danilobuerger]

I haven't checked wether this is still an issue or not. But I am reopening this since stale bot closed it and several people are still having an issue with it.

[maulikdhameliya]

I am getting the same error. When there is an error in watchQuery, it stops and never polls again. I think this issue should be fixed ASAP.

[KillerCodeMonkey]

so i do not have this problem any more. Network errors are handled like graphql errors and your error callback gets executed.

There you can check, if it was a network error or something you like to handle and use.

QueryRef.startPolling() to restart polling or QueryRef.refetch to try it again.

And if you want to handle some network errors i recommend using http-retry-link.
It retries requests a specific amount of times. If this does not work the network error is thrown (but then you do not need to restart polling, because in most cases there are some fatal errors like the server is not running or you do not have internet connection for real).

[maulikdhameliya]

@KillerCodeMonkey thanks for reply. so you are saying that in latest version above problem fixed without doing much at app side?

[KillerCodeMonkey]

it is fixed, because i can handle network errors (which does not work for me previously).
So i am able to restart polling ;).

When your subscriptions error callback is called, then your query fails, and so the polling. so you have to restart it on your own ;).

If you want o continue polling and ignoring such errors, you need to create your own link, catch network errors and returning latest data from cache or something like that.

Apollo should not continue polling if any error occurs!

[hwillson]

This should now be resolved, but let us know otherwise. Thanks!