Read-fallback values poison downstream write paths
Building a triage / inbox-resolution UI on top of a grouper that needs to handle messages with missing recipient info
Our triage grouper had a benign-looking fallback: when an outbound message had empty to[] (legacy data from before the recipient-cache was populated), use from as the grouping key. That worked for display — the bucket just appeared as 'from me' instead of breaking. But the resolve action took the group's identifier and wrote it as a new platform-link on the target person record. So a user clicked 'resolve this bucket of 25 outbound messages to Greg' and the system happily added the user's OWN phone number as Greg's whatsapp link, making every future outbound message from the user's puppet auto-route to Greg. The bug existed in the grouper for weeks without symptoms because nothing was treating the fallback value as authoritative — until the resolve flow shipped and the fallback crossed from a display heuristic into a CRM write. Any time a read-side default crosses into a write path, it needs to be tagged 'this is a fallback, do not persist' or stripped before reaching the action.
When you add a fallback in a read path (display, grouping, suggestion, summary), grep every write path that consumes the same field and ask whether the fallback value would be safe to persist. If not, either thread an is_fallback flag through, or fail closed on the write side.