New CryptoMachine on each background operation #1704
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The background crypto process (used to decrypt notifications) relies on several rust-crypto-sdk methods that are not multiprocess safe. In particular, since the background's
MXCryptoMachine
may live in memory for days, whereas foreground's will be recreated on each app launch, we may end up in a situation where foreground has written changes to disk that the background machine does not pick up. For more details see matrix-org/matrix-rust-sdk#1415This will be fixed in the future in the rust-sdk via a
proc_lock
or similar multiprocess lock, but in a meanwhile a relatively quick solution is to recreateMXCryptoMachine
on each operation (recieve sync, decrypt event), ensuring that each time we have relatively fresh data taken straight from disk.We could addionally add
NSFileCoordinator
to provide full mutual exclusion between the processes, but this adds some amount of complexity that will be eventually moved out to rust anyway. The chance of foreground and background processing sync at the same time is minimized by explicitsession.state
checks.