Update successful delivery status for sms only if error does not exist #1150
Conversation
This file contains 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
|
@miazima just wondering, does Twilio handle retries of delivery internally? My main concern for this is that if it does retry, then we should actually update with the latest status. |
|
As discussed, Twilio does internally retry the failed requests but the callbacks that are received are the finalised delivery status of the message. |
lamkeewei
approved these changes
Apr 28, 2021
This was referenced Apr 28, 2021
Closed
Closed
Merged
Merged
lamkeewei
added a commit
that referenced
this pull request
May 5, 2021
* develop: refactor: use shared function to initialize models (#1172) chore: setup scaffolding for backend tests (#940) 1.23.0 fix(frontend): fix frontend test flakiness (#1162) fix: update successful delivery status only if error does not exist (#1150) chore: upgrade dependencies (#1153) feat: add unit tests for error states in critical workflows (#1118) feat: support whitelisting domains through `agencies` table (#1141) feat: add tests for happy paths in critical workflows (#1110) fix: prevent campaign names from causing dashboard rows to overflow (#1147) fix(email): Fix SendGrid fallback integration (#1026)
lamkeewei
added a commit
that referenced
this pull request
May 5, 2021
* develop: feat: refactor msg template components; add telegram character limit (#1148) refactor: use shared function to initialize models (#1172) chore: setup scaffolding for backend tests (#940) 1.23.0 fix(frontend): fix frontend test flakiness (#1162) fix: update successful delivery status only if error does not exist (#1150) chore: upgrade dependencies (#1153) feat: add unit tests for error states in critical workflows (#1118) feat: support whitelisting domains through `agencies` table (#1141) feat: add tests for happy paths in critical workflows (#1110) fix: prevent campaign names from causing dashboard rows to overflow (#1147)
lamkeewei
added a commit
that referenced
this pull request
May 10, 2021
* develop: fix: fix error when updating Telegram ID for an existing phone number (#1178) chore: upgrade React; use new JSX transform; sort imports (#1129) fix(backend): docker build and tsc output directory structure (#1177) feat: refactor msg template components; add telegram character limit (#1148) refactor: use shared function to initialize models (#1172) chore: setup scaffolding for backend tests (#940) 1.23.0 fix(frontend): fix frontend test flakiness (#1162) fix: update successful delivery status only if error does not exist (#1150) chore: upgrade dependencies (#1153)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Problem
Some SMS messages delivery statuses logged contained both the error code and a
SUCCESSstatus. This will be confusing to users who see this status in their delivery report and does not provide a conclusive delivery status of the message.Closes #1126
Solution
Bug Fixes:
SMS messages can be delivered in multiple segments when they exceed the character limit of one SMS. Hence each segment has separate deliverability and results in multiple callbacks. In the case where the first segment of the message failed to deliver but the next segment is successful, there will be a situation where the delivery status is overridden to
SUCCESSbut theerrorCodestill remains.Tests
/callback/smsendpoint with a unsuccessful delivery status - observe that the message status reflectsERRORin the db/callback/smsendpoint with a successful delivery status - observe that the message status still reflectsERRORin the db** You can replicate the bug by following this scenario on dev branch, but you will observe that the delivery status now reflects both the error code and a
SUCCESSstatus.