Inconsistent sync complete toast

[f-odhiambo]

Describe the bug
After clicking sync(On the registers menu) two toast messages are shown "Sync complete" then a second later "Syncing"

To Reproduce
Steps to reproduce the behavior:

1. Log in to Bidan, Eir and Cadre
2. Click on the menu on the top left corner
3. Click on sync
4. Two toast messages are shown Sync complete the Syncing a second later(See attached screen cast)

Expected behavior
After clicking on sync the toast message syncing should be shown then later sync complete should show.

Recorder_21122023_131103.mp4

[kelvin-ngure]

@f-odhiambo
What is happening is intentional due to a missing feature that is coming soon from the SDK. This SyncJobStatus file will show you the new ENQUEUED state coming soon

While there is an ENQUEUED WorkState for scheduled jobs, there is no such SyncJobStatus and as a result, when a job is enqueued, the RegisterFragment is instructed to mark it as FINISHED.

Since every job enters an ENQUEUED phase regardless of whether it is a periodicSync or oneTimeSync, the "Sync Complete" toast shows up immediately the jobs are enqueued. The oneTimeSync jobs quickly jump into STARTED state and so you see the "Syncing" on the UI. Then once the oneTimeSync is complete, the "Sync Complete" toast shows up for the second time

I've added some Timber entries in the code to demonstrate

[kelvin-ngure]

While looking at this, I spotted what I believe to be a bug or something that can make spotting sync issues harder. When you initially start the app, the sync ends in a FAILED state that is preceded by a GLITCH state. On the UI, the "Sync Completed" toast shows up but then a sync retry begins. The retry is expected since GLITCH should prompt a retry. I will look into the flow and figure out why the "Sync Complete" toast shows up even on failure when a GLITCH happens right before FAILED

@f-odhiambo @dubdabasoduba please let me know if we should show a "Sync Failed. Retrying..." toast or something during a Glitch as there is no handler for the GLITCH status

I've added some Timber entries in the code to demonstrate

The below shows that both types of job do enter an ENQUEUE phase so there probably be a different logic to handle them

The below shows the GLITCH phase (I have added a handler for it in the code). I am currently getting 403 and 502 errors on SID-EIR (currently following up with @f-odhiambo on that- my credentials may be bad or something else) and that is likely what causes the GLITCH. The retry is expected and that's why you see the manual oneTimeSync restart. However, as noted above, I will fix the issue where the UI shows "Sync Complete" even during a GLITCH and subsequent FAILED state

We may also need to decide how many times the app should retry sync after failure. It appears to retry indefinitely. Let me know if that is the case

[ndegwamartin]

Related ticket here #2947

[dubdabasoduba]

@kelvin-ngure did you stop getting the 403s and 502s mentioned in the comment above?

[kelvin-ngure]

@dubdabasoduba no. I just sent you some logs

[kelvin-ngure]

@ndegwamartin @f-odhiambo from What I see in the upgrade PR. To fix this, we would first need to migrate from using SyncJobStatus to using CurrentSyncJobStatus which has both work state and SyncJobStatus state representations. Is that migration something we are planning to do?

[ndegwamartin]

@kelvin-ngure yeah this needs to be done. Created a ticket here to track this #3059. Feel free to update the ticket with other info needed.

[ndegwamartin]

This is still blocked, see google/android-fhir#2472