Fix: Use SqlCipherDeletingErrorHandler in JobDatabase for corruption handling (#13762) #13798
+64
−1
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.
Previously, JobDatabase used SqlCipherErrorHandler, which did not delete corrupted
signal-jobmanager.db
. This fix ensures that SqlCipherDeletingErrorHandler is used, which deletes the database upon corruption.Closes #13762
First time contributor checklist
Contributor checklist
Fixes #13762
syntaxDescription
This pull request fixes issue #13762 by ensuring that the
JobDatabase
class usesSqlCipherDeletingErrorHandler
instead ofSqlCipherErrorHandler
for database corruption handling. The previous implementation did not delete corrupted databases, leading to potential app crashes or unhandled exceptions.Proposed Changes:
JobDatabase
constructor to initialize withSqlCipherDeletingErrorHandler
.SqlCipherDeletingErrorHandler
is used and that database corruption triggers itsonCorruption
method, resulting in the deletion and recreation of the database.Testing:
signal-jobmanager.db
in way that would ensure that the SQLCipherErrorHandler'sonCorruption
method would be called. Since it was not possible to recreate the issue/error, best way to test it was Unit testing. Corrupting the data using hex editors doesn't call onCorruption for some reason, this could be something which might need further investigation. For now, this should resolve any issue wheresignal-jobmanager.db
gets corrupted enough for ourSQLiteOpenHelper
to trigger a call toonCorruption
method. By looking closely at the logs provided by the OP, seems like in their caseonCorruption
is being called so at least for users such as them, this fix should resolve the issue.This fix ensures a better handling of corrupted databases and aligns with best practices for database error management.