Messaging | Added Detailed Carrier Message Failure Reasons to Reporting
This is the second enhancement we can make to our platform since we have decided on our go-forward strategy with our primary carriers Bandwidth and Twilio. We will now be storing the carrier-provided message failure reasons in our database and surface them in our Account & Line Usage reports.
We have captured and added 19 failure reasons that could be provided to us by the carriers. A list of all of those failure reasons can be found here.
If we do happen to see a failure reason code we have never received before, a log will be created for an unknown failure reason and we can add it to our dictionary for future instances.
NOTE: It is not a guarantee that every failed message will have a failure reason provided by the carrier, but if we receive it, we will store it and display it in the Account & Line Usage reports.
Responder Messages Automatically Displaying in Open Conversation Thread
We have added a SignalR event for when Responder messages are triggered to post the message in the thread when a conversation is open. This will prevent the need to refresh or change conversations to see if an outbound responder message was sent to the contact while you are actively in the thread.
Bug Fixes
Platform | Prevent Crash on 204 No Content - While this is an absolute edge case where an account is created manually outside of the CRUDy UI, this resolved the issue where if no contact lists exist on a newly created account, the contact page will no longer crash.
Scheduling Blast Messages Near Send Window Issue - We had an issue in our logic due to UTC time conversions that caused issues attempting to schedule a Blast send within an hour of the expiration of the account's send window. It erroneously thought it was already past the send window and would schedule it for the next morning.