Ensure that announcement emails are not re-sent - #1905
Open
becky-gilbert wants to merge 3 commits into
Open
Conversation
…e a message line exists, even if sent_timestamp is NULL, to ensure that same email is never resent
… without an existing message row that has a NULL timestamp
… row should only exclude that specific study/family/child combination from potential targets; inactive users should be excluded as potential targets
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR ensures that announcement emails are not resent if there's a failure/crash from when the message row is first created and when the timestamp is saved to that row.
Previously, if a message row existed for a given study/user/child then that would be excluded from the list of potential email targets unless the timestamp for the message is NULL. Therefore there was a chance that we would send out duplicate emails if the original attempt was successful and the problem occurred at some point between the communication with SendGrid and the message row's timestamp update in the database. This PR changes the query so that we treat any message rows with NULL timestamps as 'sent', i.e. erring on the side of not sending an email vs sending duplicates. We can always cross-reference any NULL message rows with SendGrid to see whether or a particular attempt was successful.
This also adds tests for the NULL-timestamp-as-sent case, and for two other gaps in our test coverage: