Follow-up from @jgmontoya's review on #253 (comment on crates/mdk-memory-storage/src/messages.rs).
Problem
mdk-memory-storage keeps two LRU caches that can diverge:
messages_cache: LruCache<EventId, Message> — global indexmessages_by_group_cache: LruCache<GroupId, BTreeMap<EventId, Message>> — per-group index
Because they have independent eviction, every deletion/read path currently has to double-check both caches (see delete_message, delete_messages_before_timestamp in crates/mdk-memory-storage/src/messages.rs) and merge results. This is fragile and the divergence-handling is spread across every operation.
Proposed directions
- Make
messages_cache a secondary index mapping EventId → GroupId, with the per-group BTreeMap as the authoritative store. A stale pointer is just a miss — cheap to handle.
- Or drop
messages_cache entirely and resolve EventId lookups by scanning the per-group map (acceptable if the access pattern is always group-scoped anyway).
Either way, the goal is to eliminate the "look in both, reconcile the difference" pattern that the current deletion code uses.
Context
Raised in review of PR #253 (disappearing messages), which added the deletion APIs that made the divergence visible.
Follow-up from @jgmontoya's review on #253 (comment on
crates/mdk-memory-storage/src/messages.rs).Problem
mdk-memory-storagekeeps two LRU caches that can diverge:messages_cache: LruCache<EventId, Message>— global indexmessages_by_group_cache: LruCache<GroupId, BTreeMap<EventId, Message>>— per-group indexBecause they have independent eviction, every deletion/read path currently has to double-check both caches (see
delete_message,delete_messages_before_timestampincrates/mdk-memory-storage/src/messages.rs) and merge results. This is fragile and the divergence-handling is spread across every operation.Proposed directions
messages_cachea secondary index mappingEventId → GroupId, with the per-groupBTreeMapas the authoritative store. A stale pointer is just a miss — cheap to handle.messages_cacheentirely and resolveEventIdlookups by scanning the per-group map (acceptable if the access pattern is always group-scoped anyway).Either way, the goal is to eliminate the "look in both, reconcile the difference" pattern that the current deletion code uses.
Context
Raised in review of PR #253 (disappearing messages), which added the deletion APIs that made the divergence visible.