IssueTracker

It looks like the problem is occurring in android.arch.persistence.db.framework.FrameworkSQLiteOpenHelper.getReadableSupportDatabase() and  android.arch.persistence.room.InvalidationTracker.internalInit() after a migration.  Since there is a migration the getReadableSupportDatabase() method closes the database and runs itself again.  This creates a new database which triggers RoomDatabase.onOpen() callback.  This call triggers RoomDatabase.internalInitInvalidationTracker() which which triggers the room InvalidationTracker.internalInit().  This method is generating the error  "E/ROOM: Invalidation tracker is initialized twice :/." Mentioned in #3.  The InvalidationTracker.internalInit() method short circuits since the database was already opened before the migration and InvalidationTracker.mInitialized was already set. Thus the InvalidationTracker table is not created after the migration causing the following exception.

05-08 21:36:57.745 24142-24248/com.yourmechanic.mech E/SQLiteLog: (1) no such table: room_table_modification_log
05-08 21:36:57.748 24142-24183/com.yourmechanic.mech E/ROOM: Cannot run invalidation tracker. Is the db closed?
    java.lang.IllegalStateException: Cannot perform this operation because the connection pool has been closed.
        at android.database.sqlite.SQLiteConnectionPool.throwIfClosedLocked(SQLiteConnectionPool.java:1034)
        at android.database.sqlite.SQLiteConnectionPool.waitForConnection(SQLiteConnectionPool.java:653)
        at android.database.sqlite.SQLiteConnectionPool.acquireConnection(SQLiteConnectionPool.java:369)
        at android.database.sqlite.SQLiteSession.acquireConnection(SQLiteSession.java:894)
        at android.database.sqlite.SQLiteSession.executeForChangedRowCount(SQLiteSession.java:752)
        at android.database.sqlite.SQLiteStatement.executeUpdateDelete(SQLiteStatement.java:64)
        at android.arch.persistence.db.framework.FrameworkSQLiteStatement.executeUpdateDelete(FrameworkSQLiteStatement.java:45)
        at android.arch.persistence.room.InvalidationTracker$1.run(InvalidationTracker.java:321)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
        at java.lang.Thread.run(Thread.java:764)

You can easily stop this bug with the debugger. Open up InvalidationTracker and set a break point at InvalidationTracker.internalInit() 148.  At that break point if you change mInitialized to false the `room_table_modification_log` is created and everything works as it should.

I think the InvalidationTracker class must be reset or recreated when the database is closed since the room_table_modification_log table is stored in memory. Then when the database is opened again the table will be recreated.

ugh ok, we've made this change to work around an sqlite bug where it was seeing an old version of the database.
clearly not well tested sorry, we'll quickly work on this post IO.
you can stay in beta3 which is not much different than rc1 until we ship 1.1.1

Just wasted a couple of hours and wrote the same issue, but discarded it after seeing this one. Rolling back to 1.1.0-beta2

#4 it is just a log not a problem, you can safely ignore that one.

#7 Are you referring to  "E/ROOM: Invalidation tracker is initialized twice :/." Log?    I suppose you can ignore that, but in the case of a migration on 1.1.0 it shows that the `room_table_modification_log` was not created after the database was closed and reopened.

yep, the modification log thing is an error we'll fix. the invalidation tracker thing is just a log that you can ignore in this case.

I'm working on the fix, meanwhile please do not use 1.1 as it will break invalidation tracking post migration even if it does not crash.

Thanks for keeping us updated. Maybe you can wait a little longer in the future between RC and release?

we normally do (bake RCs 2 weeks). this was the push to ship things at IO :/ (conference deadlines).
and this bug was in beta but unfortunately didn't get caught until now :/

sorry about the issue, we'll ship a 1.1.1 RC soon.

No it's not just a log problem. I added the migration of adding new column of string, in the first launch the first insert fails. So the data is lost.

In my case, the error looks like:
 Cannot run invalidation tracker. Is the db closed?

    java.lang.IllegalStateException: The database '/data/data/com.pushcoin.app.reggie.debug/databases/reggie_transaction.db' is not open.

shipped in 1.1.1-rc1.
that CL only includes this fix so hopefully safe to migrate to .

I had same issue like Cannot run invalidation tracker. Is the db closed? on room version 1.0.0, but just log issue. (it didn't occur crash)
And I checked it was fixed on room version 1.1.1-rc1. I wonder when the official 1.1.1 version will be released?

we are just letting rc-1 bake to see if any error shows up. going clean so far so might release it in a week or two.
feel free to use it, it does not have any additional features etc.

I see this bug as really critical and would like to see a warning right here:
https://developer.android.com/topic/libraries/architecture/adding-components#room

That it crashes on migrations and strongly recommend users to use a previous version or the RC.

I'm getting this as well (when inserting a row after migrations), but I'm using the new Jetpack dependencies (androidx.room:room-runtime:2.0.0-alpha1). It sure seems as if the fix isn't included in that, but I wanted to double check in case the issue just hadn't been truly resolved yet.

Yup how about androidx 2.0.0-alpha1?

we'll ship a new version of androidX room to fix that. and hoping to ship 1.1.1 this week, we've not received any bugs and we see many people using it so should be fine by now.

Is this fix now ? I'm having this issue!

I could see 1.1.1 is shipped at 6/19 but androidX room hasn't released yet. :(

I am also facing the same issue

it is already shipped so please try with the latest version

it is still happened with version 2.2.0-rc01

Hitting the same issue in Room 2.2.3. Looks like it was fixed in 1.1.1-rc1 according to some old comments, but it's broken again in Room 2.X.X.

Crashing on Oneplus 6t Android 10. We're closing the database in onDestroy and seems like the only solution is to not close the database?
Room version 2.2.5

Crashing on Room 2.2.0:

Device:
Pixel XL
Android 10
Security patch: October 6, 2019
Kernel: 3.18.137-g72a7a64494e
1 Fri Sep 27 18:40:34 UTC 2019
Build number: QP1A.191005.007.A3

After few days i found solution!

I got same issue like #4. And it comes on some devices like OnePlus 6t because application relaunch MainActivity at start, so when we call database.close() in activity OnDestroy() we also need set 'null' to database instance (if you use singleton class for working with your database). So i created my own function on my singleton database class and call it on in activity OnDestroy() function. Hope its helpful!

My database class:
abstract class AppDatabase: RoomDatabase() {
    abstract fun TestDao(): TestDao

    companion object {

        @Volatile
        private var INSTANCE: AppDatabase? = null

        fun getDatabase(context: Context): AppDatabase{
            val tempInstance = INSTANCE

            if(tempInstance != null){
                return tempInstance
            }

            synchronized(this){
                val instance = Room.databaseBuilder(
                    context.applicationContext,
                    AppDatabase::class.java,
                    "database_name"
                    )
                        .build()
                INSTANCE = instance
                return instance
            }
        }

        fun closeConnection() {
            if(INSTANCE != null){
                Log.i("room", "reset instance")
                INSTANCE!!.close()
                INSTANCE = null
            }

        }
    }
}