Reachability class prone to indicate a false positive of client's connectivity about amplify-js

[cwomack]

Hello, @luisenaguero and thank you for opening this issue. I'm going to mark this as a feature request at this point after reviewing this with the team internally.

The purpose of the exponential backoff is to avoid inundating infrastructure that's attempting to come back online. That could be AppSync or any piece of "network" between the client and AppSync. Regardless of the network, it's a "best practice" to back off to give the "thing that's down" or unavailable room to breath and come back online.

That said, exponential backoff should inherently retry a handful of times very quickly. If the network is still connecting, I would expect reconnect within seconds and retry to also succeed within a few seconds. If the network is "down", I'd similarly expect exponential backoff to at least be proportional to the time to recovery.

[schutzelaars]

Our customers are experiencing the same issue where DataStore seems to be stuck syncing ('ready' not being emitted) on devices with very poor internet connections.

@luisenaguero could you share a code snippet of your workaround?

[luisenaguero]

Hey, @schutzelaars !

What we ended up doing for now was to have the Reachability class to not only listen the online/offline events but also have it be subscribed to our own BroadcastChannel which receives a message based on a heartbeat we placed in a ServiceWorker that every so often makes a request to an url to verify the connectivity.

Reachability class

...
const broadcastChannel = new BroadcastChannel('CHANNEL_NAME');

return new Observable(observer => {
	observer.next({ online: globalObj.navigator.onLine });

	const notifyOnline = () => {
		observer.next({ online: true });
	};
	const notifyOffline = () => {
		observer.next({ online: false });
	};

        broadcastChannel.onmessage = (event) => {
           // checks the message
           // calls notifyOnline or notifyOffline accordingly 
        };

        return () => { 
           broadcastChannel.close();  
           ...

Service worker

...

const broadcastChannel = new BroadcastChannel('CHANNEL_NAME');

function simplifiedConnectivityChecker() {
  // pings url to verify
  broadcastChannel.postMessage(ONLINE/OFFLINE);
  ....
  // gap time
  simplifiedConnectivityChecker();
}
...

If the client has poor connection, either way this might not be completely accurate.
For this case we added like a timeout when pinging the url and if it takes longer than x secs, we considers it as if there's no connection.

Hope this helps.

[schutzelaars]

Thanks!

In the near future, I'll also implement a connectivity checker. Did you encounter any gotchas when implementing the simplifiedConnectivityChecker function?