Technical Details

• Component used: Room + Paging 3 (particularly LimitOffsetPagingSource class)
• Version used: Room (2.6.0-rc01), Paging (3.3.0-alpha02)
• devices/Android versions reproduced on: Emulator (API 34)

This sample app showcases how there is no error propagation available when using default PagingSource in queries. The sample app has a text field that filters a list of animals. The MATCH statement is used to throw an Exception but there may be other ways to do this as well.

Steps to reproduce:

1. Build and run the app
2. Click the CRASH button or type "OR" into the text field
3. Set the PREFLIGHT_ENABLED flag to true, run the app again and the crash will not happen

Under the covers, the default implementation of PagingSource in DAO queries is LimitOffsetPagingSource.

• Exceptions are not propagated on the coroutine scope the query is called on for handling.
• Exceptions are not propagated to the database query executor for handling.

In this particular case, we have options to mitigate this:

1. We can preflight all MATCH requests before executing PagingSource DAO queries (demonstrated in this app)
2. We can write our own PagingSource that handles exceptions ourselves
3. There may be other solutions...

In lieu of an actual fix, there should probably be documentation that acknowledges and warns about situations using the default PagingSource, particularly in instances where the MATCH statement is used with user input since this is a common use case with FTS4 entities that requires special care.

There are a few StackOverflow issues that mention this issue, both reported years ago, but I could not find any bug reports:

• https://stackoverflow.com/questions/63657792/how-do-we-handle-runtime-errors-from-room-generated-paging-code
• https://stackoverflow.com/questions/59859531/how-to-catch-unhandled-exceptions-in-the-room-persistence-library?rq=4