Synthetic matrix: Twilio status callbacks arriving in the wrong order, and the stored result each must give

Invented data, an authored rule

Every message identifier below is invented. The rule is an authored specification for a store, not a Twilio behaviour: each status has a rank, a callback is applied only if its rank is higher than the stored rank, and the three end states share the top rank. Where two different end states arrive, the first is kept and the conflict is recorded for a person. This is a worked test specification, not an executed integration, and it shows nothing about any real message.

• Ranks: queued 1, sending 2, sent 3, delivered, undelivered or failed 4.
• An ignored callback is logged with its reason, not discarded silently.
• An unsigned or wrongly signed request is rejected before any of this runs.

If the matrix is wider than the box, scroll horizontally to read every column. Keyboard: focus the matrix and use Left/Right.

case | arrival order                                  | stored final | log
-----+------------------------------------------------+--------------+----------------------------------------
1    | queued, sending, sent, delivered               | delivered    | 4 applied
2    | queued, sent, sending (late), delivered        | delivered    | 'sending' ignored (rank 2 < 3)
3    | sent, delivered, sent (replayed)               | delivered    | 'sent' ignored (final already stored)
4    | queued, sending, undelivered, delivered        | undelivered  | 'delivered' recorded as conflict, flag
5    | queued, failed                                 | failed       | 2 applied
6    | signed 'sent' for a SID not in the table       | (none)       | unknown SID logged, no row created
7    | 'sent' with a missing or wrong signature       | (unchanged)  | rejected, no change

What each case proves

Case 2 and case 3 are the heart of the matter: the late arrival has a lower rank than what is stored and must not overwrite it. Case 4 shows a policy choice that has to be made by the owner of the data, because two end states cannot both be true; keeping the first and flagging the conflict is one defensible choice, not the only one. Cases 6 and 7 separate unknown messages from untrusted requests.

• Cases 1 and 5 are the ordinary paths and must still pass.
• A hidden eighth case is worth adding for any status the provider adds later: unknown statuses are logged and never lower a stored rank.
• The stored history should list every applied change with a time.

What was and was not exercised

The sequences were checked by reading the rule against each row. No Twilio account, callback, signature or database was exercised in producing this table, and no real delivery behaviour is claimed. A real acceptance run would post signed test requests in these orders to the actual handler and compare the stored row and log with the table. Twilio test credentials produce no status callbacks, so a live send to a phone you own is needed for the delivery path itself.

• Error codes are stored as reported; no rule here branches on a particular code.
• Segmented messages and other channels are outside this table.

Use it in a scoped enquiry

If your app needs this behaviour for one notification type, the single Twilio outcome is priced from a fixed £345 as an untested test price, with payment after the agreed checks pass and you sign off. Send the table of cases you want, edited to your policy, and the event that sends the text; do not send phone numbers, credentials or message contents. Sender registration and consent rules stay with your account holder.