For four months our delivery reports said everything was fine
A status column that has never held the word failed is not proof that nothing failed.
A car-services business we are related to confirms bookings by WhatsApp. One customer agreed a price and a date and never heard back. Every screen we own said he had been told.
The night one confirmation failed
A booking confirmation went out. Nine seconds later the messaging provider replied that it could not be delivered. Our system logged that it did not recognise the status, skipped the report and left the message marked as sent.
The customer had agreed a price and a date and heard nothing. Nothing we owned could have told us.
Why every failure branch was dead
The code that reads delivery reports compared the status name against the provider's group names: rejected, undeliverable, expired. The provider's status name is the specific one, with the group as a prefix, so it can never equal its own group.
It looked healthy because the two branches that did work, delivered to handset and delivered to operator, use real status names. Deliveries were recorded and failures never were, which is the most reassuring way for this to break.
The fingerprint was in the data
Across the 80 messages sent since April, the status column had only ever held two of its five values: 58 sent and 22 delivered. Never failed, never pending, never read.
A column missing three of five values is the fingerprint of a dead mapping, and it had been sitting there for four months. We can no longer say how many of the 58 messages arrived, because the evidence only existed in log retention.
One rule, written twice
The send path already read the right field and said why in a comment. The delivery-report path was a second copy of the same rule, and the second copy was wrong. The fix applied the first copy's rule to the second.
Making failures reachable also made a new risk reachable: reports arrive out of order, so a late "pending" could walk a delivered message backwards. Writes are now limited to updates that move a message forward, and a failure can never overwrite proof of delivery.
What we checked
The new tests were run against the old mapper before the fix. Four of them failed on the exact report that had been skipped in production, and they passed after.
- Look at the spread of a status column. If a state has never occurred, find out why.
- Feed the real failure back in. Use the provider's actual reply, not a value you invented.
- Look for the second copy of a rule. When two places decide the same thing, one is wrong.
Want to know your reports can actually report a failure?
We break things on purpose and check that the dashboard notices. The first month is a trial.
