Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

CacheAndNetwork immediately throws ApolloNetworkException when offline #5211

Closed
hbmartin opened this issue Aug 27, 2023 · 4 comments
Closed

Comments

@hbmartin
Copy link
Contributor

hbmartin commented Aug 27, 2023

Version

3.8.2

edit: Tested with 4.0.0-alpha.3 and this issue does not occur 馃槃 (I'm wary of shipping with an alpha version though.)

Summary

CacheAndNetwork emits a cache hit and then an error in the case of a server error.
However, the call immediately throws ApolloNetworkException when offline with no cache emission.

Steps to reproduce the behavior

I have query run as: apolloClient.query(...).fetchPolicy(FetchPolicy.CacheAndNetwork).toFlow().catch { ... }

This behaves as I expect when requesting while the device is online but some other server error occurs (i.e. if I set invalid auth). Specifically, I first see the cache hit emission and then see an error in my catch block.

However, when I take the device fully offline, I immediately get an error with no cache hit. Wrapping SqlNormalizedCacheFactory in a logging factory, I am able to observe successful cache hits in this case, but there is no cached data emitted and catch happens immediately.

@hbmartin
Copy link
Contributor Author

I've tried modifying FetchPolicyTest but haven't been able to figure out how to run the test. If I can get some instructions on that I'd be happy write up a test case!

@martinbonnin
Copy link
Contributor

Hi 馃憢

Tested with 4.0.0-alpha.3 and this issue does not occur 馃槃 (I'm wary of shipping with an alpha version though.)

Indeed, this behaviour changed quite a bit in v4. You can read more about it in this RFC

In v3, you can set ApolloClient.Builder.emitCacheMisses(true) to emulate that behaviour although I'd encourage you to use the alphas. Alphas are more about API stability than feature stability.
For all matters, v4 get the fixes and additions faster than v3 these days.

@hbmartin
Copy link
Contributor Author

@martinbonnin fantastic, thanks! Closing this.
For my future reference, any suggestions on test running?

@martinbonnin
Copy link
Contributor

FetchPolicyTest is an integration test, you can run it with something like so: ./gradlew -p tests :integration-tests:build

You can also open the tests subdirectory in your IDE and it should show the small green triangle in the gutter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants