I have had a read through all the issue reports relating to the CursorWindow errors and done some code analysis.
Here are the facts: The "Row too big to fit into CursorWindow" error will occur when the size of a single record returned in a select query is greater than the cursor window size which is defined for Android devices specifically. The default size set by Android is around 2mb for most platforms. There is a workaround implemented in the Joplin code to override this value and set it to 50mb.
I have created a note in Joplin desktop which is approx 4.8mb in size and exported it as a jex file (big.jex). Using Android emulator on Android 15, I am unable to reproduce the error by importing big.jex. However, if I remove the workaround implemented in MainApplication.kt and build the code locally, I am able to reproduce the error by simply importing big.jex (no sync setup is required).
This proves that the workaround implemented in MainApplication.kt does work, which is why the Joplin team have not been able to reproduce the error. Looking at the user feedback, in one example it was reported (in a version of Joplin which had this workaround implemented) that the error occurred selecting from revisions, despite not having any individual note which is 50mb or greater in size that could create a revision so large.
I think the most likely cause of the error is due to the logic to override the window size to 50mb not working on some devices. It does not appear to be related to the version of Android, or how powerful the phone is, as it has been reported on old and new phones including high end ones. Therefore I am guessing producing the issue is dependent on the bundled version of sqlite which comes with the Android device. This is supposed to be dependent on the version of Android, however the link here android.database.sqlite | Android Developers says "Some device manufacturers include different versions of SQLite on their devices".
My guess is that if the manufacturer bundles a non standard version of sqlite, it may not use the CursorWindow class, therefore rendering the workaround in Joplin useless.
In the issue reports regarding the error, users have experienced this issue when selecting from 1 of 3 tables: notes, resources and revisions. Therefore, in the event that the user had a device where the workaround does not work correctly, for each of these tables, it would be possible to produce the error in the following scenarios:
-Notes: Having any note which is greater than 2mb would cause the error
-Resources: The resource is not stored in the database, however the OCR text is. Therefore if using OCT, then if the OCR text is greater than 2mb, this would cause the error
-Revisions: If at any point you have a note which is greater than 2mb in size, if the large content is pasted all in one go, or if the revision service 'merges' multiple revisions where it grew gradually, a revision over over 2mb could be created and would cause the error. Once this revision exists on the Android device, it can only be deleted by uninstall, reinstall and re-sync of the profile on the device.
Therefore, if you are someone who has an affected device, you will have to bear in mind these limitations if using an Android device as a client, as this issue probably can't be fixed. For all other users who are not affected by this issue, the 50mb limit instead will apply for each of the above scenarios.
