Error on Sync Issue in Android Application

[andrineM]

Background Information

We currently have more than 50 new implementations of CHT across the country with further scaleup likely from October 2021 when care and treatment partners will have renewed grants.

Issue
Whereas we pride in the new implementations, they have all reported the inability to synchronize data between mobile devices and (CHT) server after the initial setup. The browser cache must be cleared to allow for fresh setup of the application and that leads to data loss. The 3 pilot health facilities must clear browser cache at regular intervals (every morning) as a workaround to the problem although that has not worked for the new implementations.

We have been in touch with the implementations and our team was able to reproduce the issue with a local instance of CHT. Kindly find the screenshots showing the errors for

Summary

This text will be hidden

review. We look forward to your guidance and a possible short-term workaround even as we plan for a long term solution.

Please use the below procedure to reproduce the issue.

1. Install firefox browser in a mobile device i.e. phone, tablet
2. Connect to a locally hosted CHT and have data synchronize for offline data capture- typical of our health facilities
3. Disconnect the mobile device from network and enter a few forms
4. Reconnect the mobile device to the network and attempt synchronizing data to the server
   @antony

ScreenShortError5|690x178

[ojwangantony]

Thanks @andrineM for sharing this. Looking forward to hearing from the team.
@derick

[diana]

I have followed your reproduction steps, using a local deployment and have had no issues in syncing once the device was back online. For reference, CHT was running the latest master, my mobile device is running Android 11, using Firefox 92.1.1 . I used airplane mode to disconnect/reconnect to the network.

Is your CHT deployment accessible from the device when you try to sync? Could you please try the server’s URL in an incognito tab and see if the login page loads?

Additionally, please include the whole logs from the browser console, and also please include the device’s network log.
In the image you attached, you can see there is a Network Error. If the device cannot reach the instance, synchronizing is impossible.

Thank you.

[nyika]

@andrineM , I am keen to know why you prefer to use the browser on mobile and not the android app? Also, could the browser have some security setting that’s killing outgoing requests to the server? The screenshot you shared shows that something is wrong with the network.

[ojwangantony]

Our implementations are offline and have no SSL configured and thus cannot work with the CHT app which requires the same for data synchronization.

[ojwangantony]

@ekaunda and @chesterosoronyas can provide more feedback on this.
Thanks

[chesterosoronyas]

Kindly note @diana this is based on how the issue came about:

1. The clients would use the tablet for a long time and would sync after couple of days to the server.The clients clarified they were not able to sync data after 9 days.
2. I also found that when there is poor network and one is not able to connect the device then the sync feature would not work after the network is back to normal. This depends on the network. I request you try to use the sync feature in a places with poor network connection or unstable network.

Kindly find the log trail which indicates the same error.Kindly note the error is still the same with screenshots.

13:06:09.284 Initiating changes service inbox.js:3:1236663
13:06:09.959 Persistent storage granted: storage will not be cleared except by explicit user action inbox.js:3:1236663
13:06:10.405 RulesEngine Status: Disabled inbox.js:3:1236663
13:06:10.573 Initiating changes watch (meta=false) inbox.js:3:1236663
13:06:10.579 Initiating changes watch (meta=true) inbox.js:3:1236663
13:06:19.368 Replication started after NaN seconds since previous attempt inbox.js:3:1236663
13:06:19.479 Replication started after 0 seconds since previous attempt inbox.js:3:1236663
13:06:19.820
Object { result: {…}, stack: “” }
Possibly unhandled rejection: {“result”:{“ok”:false,“start_time”:“2021-09-17T10:06:19.490Z”,“docs_read”:0,“docs_written”:0,“doc_write_failures”:0,“errors”:[],“status”:“aborting”,“end_time”:“2021-09-17T10:06:19.805Z”,“last_seq”:0}} inbox.js:3:1236663
13:06:20.136 Error replicating from remote server
Object { result: {…}, stack: “” }
inbox.js:3:1236663
13:06:20.147 Error replicating from remote server
Object { result: {…}, stack: “” }
inbox.js:3:1236663
13:06:20.160 Error replicating to remote server
Object { result: {…}, stack: “” }
inbox.js:3:1236663
13:06:20.168 TypeError: NetworkError when attempting to fetch resource. Possibly unhandled rejection: {} inbox.js:3:1236663
13:06:20.179
Object { result: {…}, stack: “” }
Possibly unhandled rejection: {“result”:{“ok”:false,“start_time”:“2021-09-17T10:06:19.382Z”,“docs_read”:0,“docs_written”:0,“doc_write_failures”:0,“errors”:[],“status”:“aborting”,“end_time”:“2021-09-17T10:06:20.135Z”,“last_seq”:0}} inbox.js:3:1236663
13:06:20.183
Object { result: {…}, stack: “” }
Possibly unhandled rejection: {“result”:{“ok”:false,“start_time”:“2021-09-17T10:06:19.387Z”,“docs_read”:0,“docs_written”:0,“doc_write_failures”:0,“errors”:[],“status”:“aborting”,“end_time”:“2021-09-17T10:06:20.159Z”,“last_seq”:0}} inbox.js:3:1236663
13:06:20.191 Error replicating to remote server
Object { result: {…}, stack: “” }
inbox.js:3:1236663
13:06:20.215 Replication failed after 0.738 seconds inbox.js:3:1236663
13:11:19.489 Replication started after 300 seconds since previous attempt inbox.js:3:1236663
13:11:20.017 Error replicating from remote server
Object { result: {…}, stack: “” }
inbox.js:3:1236663
13:11:20.027 Error replicating from remote server
Object { result: {…}, stack: “” }
inbox.js:3:1236663
13:11:20.040 TypeError: NetworkError when attempting to fetch resource. Possibly unhandled rejection: {} inbox.js:3:1236663
13:11:20.047
Object { result: {…}, stack: “” }
Possibly unhandled rejection: {“result”:{“ok”:false,“start_time”:“2021-09-17T10:11:19.496Z”,“docs_read”:0,“docs_written”:0,“doc_write_failures”:0,“errors”:[],“status”:“aborting”,“end_time”:“2021-09-17T10:11:20.016Z”,“last_seq”:0}} inbox.js:3:1236663
13:11:20.074 Error replicating to remote server
Object { result: {…}, stack: “” }
inbox.js:3:1236663
13:11:20.081
Object { result: {…}, stack: “” }
Possibly unhandled rejection: {“result”:{“ok”:false,“start_time”:“2021-09-17T10:11:19.502Z”,“docs_read”:0,“docs_written”:0,“doc_write_failures”:0,“errors”:[],“status”:“aborting”,“end_time”:“2021-09-17T10:11:20.074Z”,“last_seq”:0}} inbox.js:3:1236663
13:11:20.090 Error replicating to remote server
Object { result: {…}, stack: “” }
inbox.js:3:1236663
13:11:20.108 Replication failed after 0.625 seconds inbox.js:3:1236663

[gareth]

Thanks @chesterosoronyas . It looks like the PWA is unable to connect to the server the next day. There are multiple reasons why this might be happening and unfortunately that log doesn’t provide much detail to narrow down which it is.

If you can reproduce it again, there should be more information available in the Network tab of the browser’s developer console. Once there you will see the replication requests being attempted. From there you can see the “Status” code and any response from the server which will help narrow this down.

[derick]

@chesterosoronyas are you able to reach your server (by IP address or FQDN) from the affected devices (entering the address on an incognito browser tab)?

[ekaunda]

Thanks @andrineM for sharing the issue. I happened to have encountered the same issue at one of our pilot sites. We are doing an offline implemention and the devices using for entry by our HTS providers are Samsung J7 Phones running on Android 7.0 and Mozilla Firefox version 91.1.0

Connection url to the CHT application:
To connect to the cht instance, the users are using the url https://192.168.0.1:7200

Reproducing the Issue
The data sync issue is happening mainly when a phone goes off due to low charge/battery level which eventually leads to disconnection from the CHT server network.

You can therefore reproduce this by doing a phone restart and see if you will be able to sync data.

Below are the Logs on the Browser console :

16:53:56.530

XHRGEThttps://192.168.0.191:7200/medic/_changes?timeout=600000&style=all_docs&heartbeat=10000&since=0&limit=100

16:53:56.665

Error replicating from remote server

Object { result: {…}, stack: “” }

16:53:56.675

Error replicating from remote server

Object { result: {…}, stack: “” }

16:53:56.683

TypeError: NetworkError when attempting to fetch resource. Possibly unhandled rejection: {}

16:53:56.692

Object { result: {…}, stack: “” }

Possibly unhandled rejection: {“result”:{“ok”:false,“start_time”:“2021-09-20T13:53:55.877Z”,“docs_read”:0,“docs_written”:0,“doc_write_failures”:0,“errors”:[],“status”:“aborting”,“end_time”:“2021-09-20T13:53:56.666Z”,“last_seq”:0}}

16:53:56.750

XHRPOSThttps://192.168.0.191:7200/medic/_revs_diff

16:53:56.906

Error replicating to remote server

Object { result: {…}, stack: “” }

16:53:56.915

Object { result: {…}, stack: “” }

Possibly unhandled rejection: {“result”:{“ok”:false,“start_time”:“2021-09-20T13:53:55.884Z”,“docs_read”:0,“docs_written”:0,“doc_write_failures”:0,“errors”:[],“status”:“aborting”,“end_time”:“2021-09-20T13:53:56.906Z”,“last_seq”:0}}

16:53:56.925

Error replicating to remote server

Object { result: {…}, stack: “” }

16:53:56.965 Replication failed after 1.108 seconds [inbox.js:3:1236663]

​

On the Network tab. I am scrolling through all the Get and Post XHRs and all are giving the message No response data available for this request

@derick
On my end , I was able to connect to the server from the affected devices by entering the server IP address in incognito mode, even though on the normal browser mode, the sync issue still persists

[derick]

I was able to reproduce this 3 times today.

I installed Firefox nightly from Play store and logged in to a local server. Synced successfully.

I killed firefox on the phone and relaunched it. When I tried to sync, I get the same errors as @chesterosoronyas.

From a clean session, Firefox will give you an option of accepting the self-signed certificate. When you close it and relaunch. You do not get that option. If you look at the Network logs, you’ll see that requests will fail with a security error.

An error occurred:: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT

I’ve attached some screenshots
Clean session

After relaunching firefox

[mrjones]

@derick - you’re a testing rock star! Thanks for reproducing that - it really helps. To close the loop, if you install the *.my.local-ip.co valid cert, and then use https://192-168-1-195.my.local-ip.co - does the problem go away? Ensuring this is specifically an issue around self signed certs (it really seems that way!) will be great.

[derick]

@mrjones my session expires on exit so I have to log back in every time.

[mrjones]

@derick - well, that’s no good! Is there data loss as well as an expired session or just an expired session? I’m interested in translating any of these scenarios into bug tickets that Product Team can actionable fix. I think the first scenario (self signed cert results in MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT) is already fixed (use valid cert), but this second scenario is possibly troubling. This is effectively that a PWA on desktop or mobile (a supported scenario!), that logs you out.

I think (I hope!) this is because you’re running the default version in medic-os which is 3.9.0. Can you confirm this? If yes, can you upgrade to at least 3.10.4 (where we fixed this) and report back if you’re still logged out?

Thanks again!

[derick]

@mrjones there’s no data loss but the logout also happens with 3.10.5 and 3.11.2 (takes a couple of seconds longer than 3.10 for the session to expire)

I thought it was linked to enabling ‘Enhanced Tracking Protection’ but disabling that did not help.

[mrjones]

@derick - really nice find! Thanks for testing all that. I was able to reproduce as well. I’ve filed a ticket to track this issue.

For those having data loss - we encourage you to install a valid TLS certificate. To read more on this see this forum post and the docs on the topic.

For those getting logged out, now that you have a valid TLS certificate, either build a branded version of the CHT Android app for your deployment, or use the unbranded app with a custom URL. Either solution will reliably keep you logged in until the progress web app (PWA) issue is resolved.

[mrjones]

Oh yes! In case folks aren’t familiar with them, *.my.local-ip.co certificates are for development only. This is because the private key for the certificate is publicly available and should not be considered secure.

[antony]

HI @ojwangantony, @andrineM and @chesterosoronyas,
Please proceed to install a valid TLS certificate, retest the syncing issue and let us know if the syncing is working well as expected.

[ojwangantony]

@antony

install

Thanks, @antony. Our team will test out the recommendations and provide feedback.

Asante

[ojwangantony]

Does this mean that we have to use Pi-hole?