Cht-core: Phones with poor internet connections get an error page when trying to update

[sglangevin]

@Enock1990 experienced challenges with config updates in the field with BRAC this week. Phones received a config update and got the update notification. However, when they clicked Update, the phone tried to reload and they landed on an error page due to poor connectivity. This issue was also experienced by LG when CHPs clicked Update while the server was down.

We should investigate and perhaps handle this particular situation more gracefully - either tell the user they can't update unless they are online or make sure the update can be done completely offline.

I'm listing this as a bug, though I'm not 100% sure how updating is supposed to work.

[SCdF]

So I thought I understood how our updates work, but clearly I don't. My understanding is (was?) that once you get the update notification that implies we've successfully downloaded the whole update already, and so refreshing doesn't actually require the internet.

What kind of error page are they getting?

[Enock1990]

Let me see if i can replicate that(this is tough because I will require me to have an update though). what was happening is, after clicking on the update while there is no internet they get a ulr showing an error indicating that the user should look if the link is correct or if there is internet.... Ideally my thinking is if i click on 'update' and I don't have internet i can just be taken straight back to the App

[sglangevin]

@SCdF that was also my understanding. However, we've seen multiple cases where the user is getting an error page that they need to check their internet connection after hitting the "Update" button. Not sure if that's a 4xx or 5xx type of error. I've also heard of this happening when the server is down, so could be a 5xx error of some sort. When lg.app had some issues during a training, the CHPs who tried to hit Reload ended up on an error page.

[SCdF]

they get a ulr showing an error indicating that the user should look if the link is correct or if there is internet.

So @Enock1990 this looks like a Chrome style error then?

[sglangevin]

I've seen this on my Tecno as well and it looks similar to an error you'd get in a browser.

[SCdF]

Thoughts on this @garethbowen? Is this completely out of our control? Is it some kind of fundamental issue with the tech we're using for offline apps? It doesn't really seem possible for this to be our code being buggy…?

[garethbowen]

I agree that this shouldn't happen. It's probably a bug in our code. For example this could happen if they were redirected to the login page for some reason, because the login page isn't offline capable. It'd be great if this could be reproduced and the Network and Console tabs of the dev tools were screenshotted so we know which URL was being requested. This should be reproducible by dev. Scheduling this issue.

[alxndrsn]

I may not be doing this right, but:

1. log in as admin
2. update medic-webapp
3. wait for the update dialog to appear in the browser
4. kill medic-api
5. click the _Update_ button
6. observe:

[garethbowen]

@alxndrsn You're missing a trailing slash I think which probably means the appcache manifest URLs aren't matching any more. IIRC if you go through nginx (ie: in prod) you get redirected to have the trailing slash added.

[alxndrsn]

Thanks, I'll try to recreate on a proper server with a non-admin account.

[alxndrsn]

Steps to not recreate:

1. log in as demo
2. in a separate browser, update translations
3. disable internet
4. click the _Update_ button
5. observe that things seem to work:

[alxndrsn]

@garethbowen which URL was missing a trailing slash in https://github.com/medic/medic-webapp/issues/2328#issuecomment-222930335?

[garethbowen]

You have a URL of form:

http://localhost:5988/medic/_design/medic/_rewrite#/messages instead of
http://localhost:5988/medic/_design/medic/_rewrite/#/messages

ie: the one before the #

[alxndrsn]

If I add the missing slash locally, I see the correct behaviour:

1. log in as demo
2. update medic-webapp
3. wait for the update dialog to appear in the browser
4. kill medic-api
5. click the _Update_ button
6. observe:

[alxndrsn]

@Enock1990 @sglangevin I can't recreate this locally, but as @garethbowen said in https://github.com/medic/medic-webapp/issues/2328#issuecomment-222804687:

It'd be great if this could be reproduced and the Network and Console tabs of the dev tools were screenshotted so we know which URL was being requested.

[alxndrsn]

Cannot recreate on tecno:

1. log in on alpha.dev as demo
2. make sure phone has latest updates
3. update translations on alpha.dev
4. wait for update dialog to appear on handset
5. kill medic-core service on alpha.dev
6. click _Update_ button on handset
7. watch the loading spinner for a minute or so
8. observe that app has loaded ok
9. here's the network tab for the handset:

---

It may be a very specific network failure which causes this problem; as above it would be great to get network and console screenshots from Chrome dev tools for a device which is experiencing the problem.

[sglangevin]

@alxndrsn I think the challenge is that we have had this happen to partners during training, so CHPs are using an app where they cannot easily refresh the page. I'm not really sure how to reproduce this in a way that we could provide the dev tools console output, unfortunately. I know that doesn't really help us, though. @Enock1990 can you provide additional context about when this happened? What was the connectivity like? I have also heard that similar behavior happens when the instance is down - maybe that would be an easier way to try and reproduce?

Also, what if you try killing medic-core before the update is completely downloaded to the handset? I've also seen the update prompt appear earlier than I would expect sometimes, though that could be due to known issues with the Garden UI.

[Enock1990]

@SCdF yeah! it looked like a Chrome kind of an error. Were the training was there was bad internet: on a scale of 10, it was at 1. This happened to several phones but after trying a few more times it worked.

[garethbowen]

Nobody is pushing to get this resolved and we haven't been able to reproduce it. If this happens again we need the network tab and console logs to do more investigation. Reopen if it happens again.