no such table bookmarks_categories

[RitikaPahwa4444]

STACK_TRACE=android.database.sqlite.SQLiteException: no such table: bookmarks_categories (code 1 SQLITE_ERROR): , while compiling: SELECT * FROM bookmarks_categories

at android.database.sqlite.SQLiteConnection.nativePrepareStatement(Native Method)
at android.database.sqlite.SQLiteConnection.-$$Nest$smnativePrepareStatement(Unknown Source:0)
at android.database.sqlite.SQLiteConnection$PreparedStatementCache.createStatement(SQLiteConnection.java:1580)
at android.database.sqlite.SQLiteConnection.acquirePreparedStatementLI(SQLiteConnection.java:1112)
at android.database.sqlite.SQLiteConnection.acquirePreparedStatement(SQLiteConnection.java:1140)
at android.database.sqlite.SQLiteConnection.prepare(SQLiteConnection.java:700)

at android.database.sqlite.SQLiteSession.prepare(SQLiteSession.java:614)
at android.database.sqlite.SQLiteProgram.<init>(SQLiteProgram.java:62)
at android.database.sqlite.SQLiteQuery.<init>(SQLiteQuery.java:37)
at
at android.database.sqlite.SQLiteDirectCursorDriver.query(SQLiteDirectCursorDriver.java:46)
at android.database.sqlite.SQLiteDatabase.rawQueryWithFactory(SQLiteDatabase.java:1823)
at android.database.sqlite.SQLiteDatabase.rawQueryWithFactory(SQLiteDatabase.java:1795)
at androidx.sqlite.db.framework.FrameworkSQLiteDatabase.query(FrameworkSQLiteDatabase.kt:156)
at androidx.room.RoomDatabase.query(RoomDatabase.kt:484)
at androidx.room.util.DBUtil.query(DBUtil.kt:75)
at fr.free.nrw.commons.bookmarks.category.BookmarkCategoriesDao_Impl$6.call(BookmarkCategoriesDao_Impl.java:163)
at fr.free.nrw.commons.bookmarks.category.BookmarkCategoriesDao_Impl$6.call(BookmarkCategoriesDao_Impl.java:159)
at androidx.room.CoroutinesRoom$Companion$createFlow$1$1$1.invokeSuspend(CoroutinesRoom.kt:129)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1156)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:651)
at java.lang.Thread.run(Thread.java:1119)
Suppressed: kotlinx.coroutines.internal.DiagnosticCoroutineContextException: [androidx.compose.ui.platform.MotionDurationScaleImpl@dd4bb03, androidx.compose.runtime.BroadcastFrameClock@be0ba80, StandaloneCoroutine{Cancelling}@68298b9, AndroidUiDispatcher@83994fe

[!NOTE] This was reported by some of our users and we do not have any steps to reproduce available at the moment. An additional task would be to figure out when this happens.

[vijay2909]

https://github.com/commons-app/apps-android-commons/commit/8ff52e681560fb79e9deccd8b321afee3791c60f

@RitikaPahwa4444 Why you've incremented from 20 → 21, Even no schema or entity changes were made? Database version bumped to 21 without migration.

FYI: I've seen that the DB version keeps increasing, but no migration scripts have been written (other than 1-2 and 19→20). This can result in "no such table" errors since Room can't properly upgrade the existing schema.

[nicolas-raoul]

I don't think we increase version unless we are told to do so by the IDE or by a build error. But I could be wrong. Anyone has insights on this? :-)

@vijay2909 would you mind identifying who made the few last version increases? They might have better insights than me. :-)

[RitikaPahwa4444]

I'd gone through the release commits twice but couldn't find any room related changes. However, users were not able to start the app at all for that release and we had no option but to bump it up and release a patch immediately. It was a 100% reproducible issue - so consistent that every time you have the previous version installed and try to upgrade to the new version (the faulty one in this case), you see the crash. There was a PR as well for this that you can look up and see the issue linked to it.

Failing for some users was better than crashing for all, that too on app startup. This crash is impacting only a few flows. I know we didn't address the root cause but mitigation was necessary back then in my opinion.

[RitikaPahwa4444]

This was the issue: https://github.com/commons-app/apps-android-commons/issues/6314. Regarding the migration scripts, I don't have the historical context either 😕

[vijay2909]

@nicolas-raoul The IDE doesn’t automatically require or suggest increasing the DB version — it’s entirely up to the developer. If a build error occurs, increasing the DB version isn’t the correct fix either.

The version should only be incremented when an actual schema change is made and a proper migration is written for it. Otherwise, with fallbackToDestructiveMigration(), users will lose all their local data after updating the app.

[vijay2909]

@RitikaPahwa4444 I’m wondering why PRs that change the DB version are being merged without any corresponding migration scripts. Increasing the version number without a defined migration should always be avoided unless there’s a clear reason and it’s properly documented.

[vijay2909]

@nicolas-raoul , @RitikaPahwa4444 Could you please share the last commit before the release build? I’d like to review what actually changed and address the real cause of the issue.

[nicolas-raoul]

The version should only be incremented when an actual schema change is made and a proper migration is written for it. Otherwise, with fallbackToDestructiveMigration(), users will lose all their local data after updating the app.

Interesting! May we ping you next time we are tempted to increase the version number, to check whether we are doing the right thing? Thanks!

Could you please share the last commit before the release build? I’d like to review what actually changed and address the real cause of the issue.

We have various tracks of releases, but I believe you can find the commit you want using our tags. Thanks for checking! :-)

[vijay2909]

I'm unable to sign up.

Running betadebug app

[Kota-Jagadeesh]

I'm unable to sign up.

@vijay2909 Could you try using proDebug flavour : )

[Kota-Jagadeesh]

Hi @nicolas-raoul @RitikaPahwa4444 ,

I'm hitting a roadblock trying to confirm the database migration fix for this issue("no such table bookmarks_categories").

Problem: INSTALL_FAILED_UPDATE_INCOMPATIBLE

I can't reproduce the migration crash (v20 --> v21) because Android is blocking the update.

When I try to install my debug APK (v6.1.0) over the old official APK , I get this error:

Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE: Existing package fr.free.nrw.commons signatures do not match newer version; ignoring!]

from this i understood that this means the two apps have different security keys (release vs. debug), forcing me to completely uninstall the old app and lose the v20 database every time I try to run a test. The update process (where the migration is tested) is never triggered.

What I tried

1. Installed Old Version: I successfully installed the official v4.2.1 APK.
2. Attempted Upgrade (Failed): I used adb install -r -d -t app-commons-v6.1.0-main-prod-debug.apk to force the upgrade of my local debug build over v5.5.
3. Result: The signature mismatch error blocked the in-place update.

Since I am unable get my debug APK to update the official APK on my device, i just wanted to know an easy way to proceed with testing the migration.

Do you have access to: Debug Signed APK for the OLD version (DB v20)? If I install this first, I can update it easily with my locally built debug APK.

Could you advise mee on the easiest way for me to get a debug-signed build of an old app version so I can properly test the database migration path?

Thankks!!

[nicolas-raoul]

You can build and use unsigned APKs to reproduce the issue, I think. 🙂