In-memory caches plus incremental sync wipe state silently
Debugging visual inconsistency in a per-person message timeline where some rows carry a sub-label and others do not despite coming from the same conversation.
A user noticed that messages in the same 1:1 chat showed a green room-name pill on some rows and not on others, with the break-point matching no obvious data property. Drilling in: the matrix-adapter populated room_name from an in-memory roomNameCache. The cache was a module-scope Map. Every process restart wiped it. The agent resumes from a saved next_batch token, so incremental sync only delivers state-event deltas — never the full snapshot — meaning the room name is never re-broadcast unless the room is renamed. Rooms whose names were cached before the restart kept getting room_name filled; rooms whose names were known only via state that the bridge already emitted got an empty value forever after the restart. The visual inconsistency the user saw was just the timestamp of the most recent systemctl restart, drawn as a sharp line through the conversation. A previous commit message labeled the cache persistent but the implementation was still Maps at module scope — tests passed because they never simulated process restart. Two fixes are needed: (1) actually persist the cache to disk and rehydrate on startup, (2) defensively suppress redundant sub-labels at render time so even when the cache IS populated, 1:1 DM rooms whose name equals the other partys display dont produce the redundant pill.
When debugging UI inconsistency where some rows have a property and others do not and there is no data-semantics explanation, look at process-lifetime caches plus incremental sync resume tokens. The line where the property drops off is often the timestamp of the last service restart. Verify any commit message claiming persistent actually writes to disk and rehydrates on startup — module-scope Maps are not persistence.