Disambiguate 'sending' message state

[bchrobot]

Is your feature request related to a problem? Please describe.

The SENDING message status is currently overloaded. It could mean either a) issues in Switchboard or b) standard delays or queuing downstream. End users have no way to distinguish between the two and often open tickets concerned about a) when the issue is actually b).

Describe the solution you'd like

Revamp message status to better differentiate message state:

• default state upon insert into Spoke database (currently 'SENT'?)
• received by switchboard
• passed on to aggregator ("Received by telecom provider")
• aggregator 'sending'

Describe alternatives you've considered

Leaving message states as-is and providing additional documentation/clarification instead.

Additional context

Further discussion in private Slack here.

[bchrobot]

Feedback requested from any/all @politics-rewired/organizing @hiemanshu @ajohn25 @ben-pr-p @ikehz

[bengilvar]

Organizing team loves breaking SENDING out into 4 distinct states!

[hiemanshu]

Changes required for each step of the way:

1. Change in spoke, to update status to "QUEUED" once message has been sent to Switchboard.
2. Once the message has been received by Switchboard, the status is updated to "<need status name here>"
3. Switchboard sends the message to the telco, and once telco has recieved the message, switchboard calls /assemble-numbers-message-report and gives a report about message being sent, and spoke updates the status to "<need status name here>"
4. No change here to change status to "DELIVERED"

@bchrobot thoughts?

[bchrobot]

@hiemanshu I don't fully follow. Are blank statuses in 2 and 3 placeholders, or actual blanks?

I think the first step is to map states and state transitions in Telnyx and Bandwidth (and maybe Twilio too) onto Switchboard and from there onto Spoke, then decide the best way to display that to end users, and then figure out the implementation details/changes.

[hiemanshu]

@hiemanshu I don't fully follow. Are blank statuses in 2 and 3 placeholders, or actual blanks?

Ah, they are place holders, I typed <NEEDS NAME> and I think Github formatting removed / changed that

I think the first step is to map states and state transitions in Telnyx and Bandwidth (and maybe Twilio too) onto Switchboard and from there onto Spoke, then decide the best way to display that to end users, and then figure out the implementation details/changes.

Sounds good! Looks like a good first issue for me to take up in Switchoard.