Prevent/Recover from DB corruption in runtime #6014
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.


🎯 Goal
We have reports of crashes originating from the DB caused by performing write operations after the DB has been corrupted. With this PR we are adding several guards and optimistic improvements that would:
🛠 Implementation details
Mutexlocks for write operations on the same table (follows the pattern established in theDatabaseChannelRepository/DatabaseMessageRepository->scope.launchWithMutext(mutex) { writeOperation() }, which runs the write in a new coroutine, locked on the providedMutex)Recoverable<Entity>Daoclasses, which are wrappers around thelazygetDatabase().getDao()which always retrieves a Dao from the current DB instance, instead of keeping a reference to the initially retrieved DAO.🎨 UI Changes
NA
🧪 Testing
Corrupt DBbutton, which will attempt to simulate a DB corruption, and insert a dummy user afterwards.Corrupt DBbutton - sometimes multiple attempts are required in order for the DB to become corruptedChat:StreamSQLiteCallback-onCorruption called for DBit means that a corruption happenedProvide the patch summary here