[MS-936] Fix the db locked issue by Refactor EventDatabaseFactory to create a single instance of the event DB#1139
Merged
Merged
Conversation
meladRaouf
requested review from
BurningAXE,
alex-vt,
alexandr-simprints and
luhmirin-s
BurningAXE
reviewed
Mar 12, 2025
| @@ -82,16 +84,10 @@ internal open class EventLocalDataSource @Inject constructor( | |||
| ex.let { it as? SQLiteException }?.message?.contains("file is not a database") == true | |||
|
|
|||
| private suspend fun rebuildDatabase(ex: Throwable) = mutex.withLock { | |||
Contributor
There was a problem hiding this comment.
Renaming this function to recreateDatabase would make it match the one in EventDatabaseFactory and more appropriately convey what it's doing. (Yes, I was the one to name it...)
BurningAXE
reviewed
Mar 12, 2025
| coEvery { securityManager.getLocalDbKeyOrThrow(dbName) } returns localDbKey | ||
| mockkObject(EventRoomDatabase) | ||
| val db: EventRoomDatabase = mockk() | ||
| every { EventRoomDatabase.getDatabase(context, any(), dbName) } returns db |
Contributor
There was a problem hiding this comment.
Shouldn't this return different mocks to match actual behaviour and ensure we are not calling getDatabase() multiple times?
Collaborator
Author
There was a problem hiding this comment.
I renamed the test case as it was ambiguous. The new name is get should return the same db instance on multiple calls and it now verifies that the db is created only once
meladRaouf
force-pushed
the
bugfix/MS-936-db-locking
branch
2 times, most recently
from
1dadcf8 to
fa202a6
Compare
meladRaouf
force-pushed
the
bugfix/MS-936-db-locking
branch
from
fa202a6 to
4e4fffb
Compare
|
luhmirin-s
approved these changes
Mar 13, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
MS-936
Will be released in: 2025.2.0
Root cause analysis (for bugfixes only)
First known affected version: **it is happing in all versions
As seen in the bug ticket and Crashlytics, we are encountering multiple errors where the events' database is locked. Upon reviewing the code, I found that we are not adhering to Room's documentation guidelines. Specifically, As SID is creating multiple instances of the
EventRoomDatabaseobject, whereas the documentation states that the database instance should be shared. Using the Android Profiler, I observed that multiple database objects are being created during the biometric capture workflow and when opening the app dashboard.Notable changes
get()instead ofbuild()to retrieve theEventRoomDatabaseinstance, ensuring that the database is only built once.recreateDatabase()EventLocalDataSourceto useget()for database retrieval.recreateDatabase()functionality inEventDatabaseFactoryTesting guidance
Additional work checklist