Configurable db sync wait times

[benkags]

What feature do you want to improve? Add the ability to sync sooner from the server on a case by case basis e.g by deployment

Describe the improvement you'd like The experience for 2-way texting using the messaging tab is not the best when an offline user has to wait for 5 mins when they send a message or when expecting an SMS response from a user. #5738 should cater for sending a message to the server promptly but does not address receiving a message from the server.

Describe alternatives you've considered Training the user to manually trigger sync after every message or when expecting an SMS response from the user.

Additional context

[abbyad]

This may be related to sending Outbound Push without delay #6306

[garethbowen]

As well as reducing the sync time there are cases where we'd want to increase the sync time to reduce the load on the server.

Furthermore, it's likely we'd want to configure the time between replications to the server separately from the replication from the server. That way, projects that generate most of the data on the phone can replicate it to the server frequently, but only check for updates to download occasionally.

As one final complication, it's also possible that app builders would want different sync times for different roles.

[abbyad]

~@benkags is this about the replication of an offline-first user's local changes being attempted whenever a new doc is created/updated, rather than on a schedule?~

~If so, the intended behaviour as per 3.4 was that a replication would be attempted when the user creates or updates a document. That would mean that you don't have to press "sync now", and would solve this issue. However, the replication when a doc is created/updated may not have been implemented as such, in which case this is a bug.~

~Beyond fixing that presumed bug, do you think this needs to be further configurable?~

Edit: I see that fixing that "bug" I asked about is already being discussed in a separate issue and that this issue is in fact for configuring the time to replicate when there are no local changes, which affects how quickly you pick up changes on the server.

[abbyad]

This seems related to https://github.com/medic/medic-android/issues/93 as well, but for messages. There are cases like messaging, or tasks created by others, where we'd want remote changes to notify the user (eg push notifications).

[joyannee]

@benkags @Maigua please add context here from the i-tech projects based on our discussion today. Is this a blocker at the moment?

[SCdF]

Any work on this ticket should be charged to: 117 I-TECH-Zimbabwe

[joyannee]

ping @benkags @Maigua please add more context about this issue and importance for scale up. Based on our conversation last week, this feature could help during scale up of this project but we have no budget for new feature development for this project and as I understand we are not configuring any COVID use cases for this project hence we can deprioritize it for now?. Is this still the case?

[Maigua]

@joyannee let's discuss this on slack and will then add more context here.

[Maigua]

@joyannee as we have discussed, not having this improvement pushed will have a serious usability issue with the end users. We do not want to hold implementing an important feature with equal importance as a task feature because of a budget constraint. I think the user need here supersedes the budgetary constraint. Kindly let's have this improvement prioritized so that we can better support our partner. In regard to having this to support COVID UC, discussions are ongoing to see how MM can utilize 2WT for COVID response. Once this is finalized, we shall all be informed.

[MaxDiz]

Hi @Maigua clarifying a few things about current message syncing functionality:

• when a message is sent, it goes out immediately
• incoming messages could take as long as 5 minutes to arrive, but could sync sooner
• a user can manually sync (in the hamburger menu) which will push/pull messages immediately

It seems like these options should answer immediate project needs. Can you please clarify the appropriate amount of time for message delivery to meet project requirements? Also, if 5min is too long of a wait time, why is the currently available manual sync option not sufficient?

[benkags]

@MaxDiz , to respond to your last question. The heart of this project is the messaging. In fact, the system is named 2wt for 2-way texting.

Here is a user story that may be helpful.

As a nurse, I want to find out the complications my client is experiencing after a VMMC operation after they sent in a distress signal to the system(clients do this by sending in a zero to the system). To do this, I want to engage this client in a near real-time back and forth conversation via messaging to understand the client's situation so that I can advise them accordingly.

You are right, manually syncing after every few seconds to check if a client has responded will work but it is not the best experience for this user. It is more of a workaround than a solution.

[MaxDiz]

Understood and thanks for the clarification. Product team resources are focused on immediate Covid response needs currently. The workaround seems manageable for project requirements (though not ideal). This issue will not be prioritized for the current release cycle. Appreciate your understanding.