fix(#306): guard every legacy-key removal, not just the channel-settings one
The previous commit fixed loadSmazEnabled and killed the post-connect stall (startup-load channelSettings: 37792ms -> 0ms, measured twice). The contact pull still choked, in multi-second bursts, each landing immediately after an "Added new contact" line. No frame handler exceeded the 100ms threshold, because the work is not in a handler: the contact handler fires _loadMessagesForContact unawaited, so it runs after the handler returns and escapes that timing. message_store.loadMessages had the same unconditional prefs.remove(oldKey), and it runs ONCE PER CONTACT during a pull. On Windows every prefs mutation rewrites the entire file, so a 234-contact pull meant 234 full multi-MB writes for legacy keys that do not exist. A sweep found the identical pattern in six more stores: contact_store, unread_store, channel_store, community_store, contact_group_store and channel_order_store. Those run once per load rather than per item, so they are far cheaper, but it is the same bug and they are fixed the same way. In every case the removal now happens only when a legacy key actually exists, paired with the write that migrates it, so the cleanup still occurs on a real migration. flutter analyze clean, dart format clean, 494 tests pass.integration/290-306-335
parent
4ee2f50703
commit
5eded9e33c
Loading…
Reference in new issue