Room cannot verify the data integrity error still showing in Crashlytics after bumping version

Question

I'm trying to figure out why a handful of my users are still getting the dreaded "Room cannot verify the data integrity" error. Whenever I get this error, I bump the version number, and it starts working again. However, I still see around 100 users still getting the crash on the latest version. I've bumped the version 5 times now and nothing has fixed it.

I have made some changes, though. I've removed some entities, and I'm constantly updating the data models. But I never get this error locally after bumping the version. Any idea why these users would still be getting it? Also, I sometimes reuse previous version numbers. Sometimes I just bump it back to 1. But the latest version is 201, which has never been used. Is it bad to reuse version numbers? Thanks in advance.

@Database(
  entities = [
    RentalResponse::class,
    UserResponse::class,
    RentalReviewResponse::class,
    SearchedLocation::class,
    SearchItem::class,
    SettingsResponse::class,
    CancellationPolicyResponse::class],
  version = 201,
  exportSchema = true
)

@TypeConverters(Converters::class)
abstract class AppDatabase : RoomDatabase() {
  abstract fun rentalDao(): RentalDao
  abstract fun userDao(): UserDao
  abstract fun reviewsDao(): ReviewsDao
  abstract fun searchedLocationsDao(): SearchedLocationsDao
  abstract fun settingsDao(): SettingsDao

  companion object {
    private lateinit var INSTANCE: AppDatabase

    fun getInstance(context: Context): AppDatabase {
      if (!this::INSTANCE.isInitialized) {
        synchronized(AppDatabase::class) {

          INSTANCE = Room.databaseBuilder(
            context.applicationContext,
            AppDatabase::class.java,
            "outdoorsy.db"
          )
            .fallbackToDestructiveMigration()
            .build()
        }
      }
      return INSTANCE
    }
  }
}

Answer 1

The only time you can re-use a version number safely is if you change the db file name, and start with a fresh db. It's then up to you to clean up the old db(s).

DB versions should only increase. It should be safe to skip versions, especially with destructive migration. So if you use versions 4, 5, and 6 while developing, you don't have to worry about setting it back to 4 when you release, you can release with 7.

Answer 2

To declare an automated migration between two database versions, add an @AutoMigration annotation to the autoMigrations property in @Database:

Sample Usage

// Database class after the version update.
@Database(
  version = 2,
  entities = [User::class],
  autoMigrations = [
    AutoMigration (from = 1, to = 2)
  ]
)
abstract class AppDatabase : RoomDatabase() {
  ...
}

Your code

@Database(
  entities = [
    RentalResponse::class,
    UserResponse::class,
    RentalReviewResponse::class,
    SearchedLocation::class,
    SearchItem::class,
    SettingsResponse::class,
    CancellationPolicyResponse::class],
  version = 201,
  autoMigrations = [
    AutoMigration (from = 200, to = 201) // your version
  ]
  exportSchema = true
)

If Room detects ambiguous schema changes and it can't generate a migration plan without more input, it throws a compile-time error and asks you to implement an AutoMigrationSpec. Most commonly, this occurs when a migration involves one of the following:

• Deleting or renaming a table.
• Deleting or renaming a column.