the-guild-org / the-guild-org/apollo-angular
Cannot recover from errors via refetch
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 1.5k
- Forks
- 309
- Avg merge
- 1h 45m
- Merged PRs (30d)
- 3
Description
Describe the bug
I am using watchQuery and refetch to update the UI, but if the watchQuery or one refetch fail with an error i can catch the error and the UI refresh the error but the next querys (refetch) dont trigger the maps, subscriptions or catchError and does not refresh the UI (even used async pipe and select pipe).
The request is send to server and the response its ok, but after one error its stops refreshing UI.
I read on apollographql/react-apollo github "Cannot recover from errors via refetch or resetStore #2070" this:
"So what happens is:
a) first query returns, error. Picked up by RA, renders.
b) refetch happens (either directly or via resetStore). Due to (a) being an error and 2. above, RA is never informed.
c) refetch query returns. In 1. above, RA compares it to the first query, which has networkStatus === 7, so it throws it away."
To Reproduce
Steps to reproduce the behavior:
- Make a request with wathQuery
- Turn off your server.
- Make a refetch (it will trigger the error catch).
- Turno on your server.
- Make another refetch (it will make the request but it will not refresh the UI, neither trigger mappings nor errors catch).
Expected behavior
When the second refetch triggers must refresh UI and trigger maps or catchErrros.
Environment:
@apollo/client: 3.0.0apollo-angular: 2.0.3graphql: 15.0.0@angular/core: 10.0.11@angular/cli: 10.0.7typescript: 3.9.5
with this other context i worked this same problem too
@apollo/client: 2.6.4apollo-angular: 1.10.0graphql: 14.0.7@angular/core: 8.2.14@angular/cli: 8.2.14typescript: 3.9.5
In fact i updated because i was hoping it was resolved.
Additional context
I workaround this by implementing interceptor, with the interceptor I catch every error and return a emtpy HTTP response (return of(new HttpResponse({body: []}));) with this it will always map because it thinks that is always correct and not an error, but when there is an error the data atribute of response in the mapping o subscribe will be undefined (response.data == undefined), meaning an error, if you want you can agregate to the response body an error atribute or the error like it was data.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the watchQuery/refetch sequence described: stop the server, refetch to produce an error, restore the server, and refetch again. Trace the Angular observable, mapping, subscription, and catchError notifications after recovery; done means the later successful refetch refreshes the UI and triggers the expected mappings or error handlers.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- angular, graphql, typescript
- Domain
- frontend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100