mautrix ghosts un-join inactive matrix rooms silently
Investigated why a bridge-based message pipeline lost recipient visibility for one specific group-chat message, after an earlier cold-start theory turned out to be wrong on closer inspection of the persisted state.
In mautrix-style bridges (whatsapp, telegram, etc.), the per-recipient ghost MXIDs do not stay joined to a matrix room indefinitely. Inactive ghosts get un-materialised — the bridge silently drops them from m.room.member state. A consumer reading matrix /sync sees ONLY currently-active ghosts, so the matrix room membership becomes a lossy view of the actual chat-platform group membership that drifts over time. Concretely: in April a group had 5 ghosts joined; by late May only the 2 most-recently-active ghosts remained joined, even though the WhatsApp group itself hadn’t changed. Any message normalised in this state has a truncated to[], so downstream fan-out routes to nobody. The fix is to NOT use matrix room membership as ground truth — read the bridge’s own SQLite (mautrix-whatsapp has portal+puppet tables, mautrix-telegram has its equivalents) for the canonical participant list, the same way you’d use whatsmeow_lid_map for LID→phone resolution. Layer the matrix-cache view on top only as a fallback for bridges without an accessible state DB.
For any bridge-based consumer: assume the bridge medium (matrix in mautrix’s case) is a lossy projection of the upstream platform’s truth, not a mirror. Identify the bridge’s on-disk authoritative state (it almost always has one) and read from there for participant/membership questions. Verify ‘cold cache’ theories against the actual persisted cache file before posting them as the root cause.