Absolute surveys erroneously regenerating and getting resent

[biblicabeebli]

It looks like some action on the website regenerates absolute survey scheduled events - @hydawo registered an absolute survey, something happened, then received those one-time absolute surveys again.

This is probably unrelated to the new work, it is probably an existing bug. @biblicabeebli check when we regenerate all schedules, we probably have something regenerating all scheduled events instead of a specific type of scheduled event.

@hydawo will test a repeat of actions on the frontend to see if he can replicate it.

[biblicabeebli]

HAHAHAHHA we call repopulate_all_survey_scheduled_events "just in case" on loading the participant page.....

[biblicabeebli]

This issue has been resolved, it was one of several issues related to interactions of how we updated push notification schedules, there was a related issue with weekly schedule notifications. We didn't see one with relative schedules, but it probably happened.

Push notification scheduling (and schedule creation, which is different) needed to be rewritten

• the investigation for issues There is no recovery mechanism for missed notifications on the iOS App, particularly multiple notifications when the app is closed. beiwe-ios#59 and Investigation of missing notifications, particularly on iOS because it does not have a fallback #402 eventually led to the correct method to accoplish that rewrite... so I guess they were not as time-wastey as I thought.
• The code now "computes the difference" between the current state of the database and the state that it should be in.
• Existing items in the database are detected and left in place - prior failures to do this could cause the error that began this thread.
• Schedule Creation had to be separately rewritten to solve the same class of potential issue.

Under the new system there is a known and intentional side effect:

• If
  • a survey schedule gets deleted
  • and then a schedule of the same type (absolute, relative, weekly)
    • and it matches the same time as an event in the survey history
    • for the same survey
  • gets created...
  • Then that notification will not be sent.
    • and there will be no indication in the notification history why this has occurred.

This change is intentional, because the mass re-sending of survey notifications for a whole study when recovering from accidentally deleting a schedule is very bad.

Some subtle details has been retained:

• Creating a new absolute or relative schedule event in the past will ~immediately cause that notification to be sent.
• Changing an intervention date will result in historical times being recalculated, and because these past events were "missed" they will get resent.
  • But they will not be resent when changing it back to the prior value on the intervention date due to the same safety mode as the side effect described previously.
  • (please don't change intervention dates after notifications have been sent.)

[biblicabeebli]

@hassan I would like to close this issue as resolved (still on staging technically)

Want to make sure that the following odd fact is preserved somewhere, maybe a comment should be added to the ui on the edit survey schedule part of the survey page (but people don't read).