Cht-core: If server is down app cannot start

[alxndrsn]

Observed

1. configure and log in to app on mobile, over local network (192.168.…)
2. close app
3. disable wifi on phone
4. enable 3g on phone

I _think_ this will reliably simulate what would happen if a server was down...

Expected

App should load. I suspect this will be hard to handle, as the ISP seems to serve the 504.

If the 504 can't be handled in browser, then the android wrapper should do something clever.

[garethbowen]

It's hard to tell but it looks like you were being redirected to the login page which should only happen if your session cookie timed out which shouldn't happen in production where we set a large timeout.

I'm wondering if the login screen should be appcached (maybe together or separately from the main app) so it can load even if you're offline. But maybe that's more annoying because you'll type in your user/pass before finding out you can't log in anyway...

[garethbowen]

Related: #1419

[newtewt]

Not getting a 504 but still getting an error. The app is unusable if the device can't connect to the server when starting. The same steps listed above were used in getting the error below.

[kennsippell]

I believe the appropriate webapp changes are in place to load while completely offline through the browser - but XWalk isn't playing well with that offline code... both service workers and appcache equally I think (?)

For example, if I go to "offline mode" through DevTools. I am able to reload the page while offline (window.location.reload()). However, if I move my phone to airplane mode or disable data (which CHVs do all the time) then I see the error page instead of the webapp.

I've attempted to stub out our custom Load Error Handler without success.

This bug basically means we have an offline-first app that can't load while offline - so it seems pretty important. I'll continue my investigation. It'd be nice to confirm that this hasn't gotten worse with service workers.

The remaining work likely isn't in the core webapp: so we might consider bumping this from the 3.5 release. This functionality seems quite important to me though and imo should remain top of the stack.

[newtewt]

I'll confirm on 3.4 and report back today.

[newtewt]

@kennsippell In 3.4 the app loads fine. I disconnected from WiFi and have no cell service. I closed the app and restarted it loads fine. Restarted the phone and loaded the app ok as well. I don't think we can bump this from 3.5.

[garethbowen]

I agree, if this has indeed regressed from 3.4.0 it's a blocker in 3.5.0.

I can't see why it would be a Crosswalk issue - I would have expected the SW to catch it and respond before it got out to Android. Is it possible it's an issue with older versions of Chrome?

[garethbowen]

Ready for AT on 3986-cache-rewrite

[newtewt]

Does this need to be tested with the android app changes as well or should the current app work with these changes? I tried using the branch listed for the android app above and built with env variable set to true. I'm sure I'm missing something about how this should work.

@kennsippell @garethbowen

[kennsippell]

@newtewt The change in medic-android is a bit of an optimization, but shouldn't be required to validate this flow. For now, let's focus on the webapp change 3986-cache-rewrite without any changes to the android app. Important to confirm that 3.5 works fine as an offline app with the existing app and that no container upgrade is required.

[garethbowen]

@newtewt Ready for AT in 3986-cache-rewrite

[newtewt]

I'm able to use the app when offline. I'm able to close and reopen when I'm offline as well. This is working now as expected.