Change Details

[ENG-11091](https://linear.app/comm/issue/ENG-11091/secondary-device-is-missing-messages-in-local-dms). This fixes the case when @ashoat logged in on the web with a full backup released before the primary uploaded backup. This worked as expected; there was a prompt with an error, and the user can decide whether to proceed with backup or ignore this and contact Comm. Later, when the updates to primary keys were sent to secondary, they were ignored because proceeding set app was in the "restored" state. However, we store the information in the store ( `forced` flag) to distinguish regular restore vs restore forced by user to log in and ignore backup issues. Based on that flag we can find out when restore wasn't concluded and avoid ignoring backup keys.

[ENG-11091](https://linear.app/comm/issue/ENG-11091/secondary-device-is-missing-messages-in-local-dms). This fixes the case when @ashoat logged in on the web with a full backup released before the primary uploaded backup. This worked as expected; there was a prompt with an error, and the user can decide whether to proceed with backup or ignore this and contact Comm. Later, when the updated primary sent keys to secondary, they were ignored because previous "log in without restoring" set the app in the "restored" state. However, we store the information in the store ( `forced` flag) to distinguish regular restore vs restore forced by user to log in and ignore backup issues. Based on that flag, we can find out when the restore wasn't concluded and avoid ignoring backup keys.

[ENG-11091](https://linear.app/comm/issue/ENG-11091/secondary-device-is-missing-messages-in-local-dms). This fixes the case when @ashoat logged in on the web with a full backup released before the primary uploaded backup. This worked as expected; there was a prompt with an error, and the user can decide whether to proceed with backup or ignore this and contact Comm. Later, when the updates tod primary keys were sentsent keys to secondary, they were ignored because proceedingprevious "log in without restoring" set app wasthe app in the "restored" state. However, we store the information in the store ( `forced` flag) to distinguish regular restore vs restore forced by user to log in and ignore backup issues. Based on that flag, Based on that flag we can find out when the restore wasn't concluded and avoid ignoring backup keys.