[Spike] Technical approach to nudge users

[mahalakshme]

Need:

Figure out the approach to send Glific message to users who have not entered data for past 5 days.

Suggested approach:

• Do in integration service to retain sanity and not to corrupt ETL
• Store custom_query to retrieve users who have not entered data for past 5 days
• Have a window such that the job should not send message to the same users for whom message was sent in the past 23 hours. So somewhere need to store the users data for whom message was sent in the past 23 hours.
• Store the manual_message in table
• Call the new api to sent glific message - one user at a time
• Currently we can retain the 4 days timeline to retry for any failed messages.
• A report with data on so far who has received message and for whom message sending has failed - If possible send notification from the report.
• For more details refer the other cards in this epic

AC:

Identify any gaps in the above technical approach and make sure the above suggestions would work.

[petmongrels]

Re: A report with data on so far who has received message and for whom message sending has failed - If possible send notification from the report.

• There are two points of failure. a) Integration service failing to call Avni Server to create a message b) Avni Server failing to call Glific.

Other options:

option 1

1. integration service calls a new avni-server api to send message
2. this new api sends the message directly to glific synchronously using the config it has for message & glific environment
3. integration service is supposed to keep retrying the failed messages anyway. We have our monitoring report connecting to integration service database.

option 2

1. integration service calls a glific to send message
2. downside - glific config and message template logic has to be replicated in integration service

[mahalakshme]

@petmongrels

Cons of option 2: i was also writing something similar

• The cons I see is duplicating the glific code and database schema in the integration and any issues we find we will only fix it in integration service and might not help in improving the common codebase
• Also from the discussions I think enhanced version of this will be asked and if done in integration - it might lead to forking out of Glific logic itself

Pros:

• I think with reporting we can attain the pros of option 2 with option 1 as well
• Why synchronously? Currently we have everything as part of bg job - what advantage will we get by making it synchronously-wont this lead to affecting the performance of foreground thread, considering we are also going to retry and there are around 1500 users.

[petmongrels]

Integration service is keeping track of which message is sent or not because the call between avni-server and integration-service can fail. If we make it synchronous there will be nothing to track in avni-server hence we need to do report only from integration service.

At max we may be sending about 100 messages in a whole day. This is also high. I don't see any performance issue here.

[himeshr]

Points of Consideration

• Release 11.0 might have to stabilize for us to make use of the GlificMsgSync API, code changes are very minial so can also be manually ported/ cherry-picked to earlier release for RWB
• Do we need to store all entries for Successful nudge for users, as well as attempts or clear them up and save only latest attempt info.?

No Major concerns found with the technical approach of synchronousUserNudge and ErrorRecord keeping to avoid repeated nudge.

[mahalakshme]

@himeshr please add your findings or approach that you suggest

[mahalakshme]

oh you have edited the same comment - just now noted @himeshr

[mahalakshme]

@himeshr yeah we need to store successful nudge as well - to show in reports - else we will not have any info to make sure if all expected users are receiving nudges - My opinion - since this is integrated system it becomes more important.