Status Update
No update yet.
Comments
[Deleted User] <[Deleted User]>
This happens when blocking thread interrupted.
Use case: RxJava, When switchMap is upstream, downstream blocking operation will be interrupted.
In older version room, runInTransaction is not interruptible, never throws exception like this.
se...@google.com
We updated Room internals to Coroutines and one of the improvements is interruption. Before the internal changes, Room would ignore thread interruption, database operations where not really cancellable, but in the latest version and due to Coroutines, Room can be interrupted but since it has to return some value which it couldn't compute it then throws InterruptedException as part of the runBlocking used to bridge blocking DAO functions with Coroutine internals. I think you will need to handle the exception as any other and determine what to return or ignore since Room can't make that decision for you.
se...@google.com
That's a big change.
I think some method should be marked with @Throws(InterruptedException::class) like runBlocking.
[Deleted User] <[Deleted User]>
runBlocking used to bridge blocking DAO functions with Coroutine internals
It seems that all non-suspend DAO query function are throws InterruptedException.
Huge migration.
se...@google.com
An update: I agree this is a big behavior change and for compatibility reasons we want to continue having Room blocking DAO functions and API be uninterruptible. We are trying to work on a solution for this.
[Deleted User] <[Deleted User]>
Project: platform/frameworks/support
Branch: androidx-main
Author: Daniel Santiago Rivera <
Link:
Use Coroutines RxJava builders in RxRoom
Expand for full commit details
Use Coroutines RxJava builders in RxRoom
The coroutines-rxjava builders have better handling for cancellation and allows Room to use Coroutine internals more natively which in turns avoids performBlocking.
Bug: 400584611
Test: RxJava2Test and RxJava3Test
Change-Id: I639162c82584eea358d061d0e2c48ce0f260a47c
Files:
- M
room/integration-tests/kotlintestapp/src/androidTest/java/androidx/room/integration/kotlintestapp/test/DeferredBooksDaoTest.kt - M
room/integration-tests/kotlintestapp/src/androidTest/java/androidx/room/integration/kotlintestapp/test/RxJava2QueryTest.kt - M
room/integration-tests/kotlintestapp/src/androidTest/java/androidx/room/integration/kotlintestapp/test/UpsertTest.kt - M
room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/test/RxJava2Test.java - M
room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/test/RxJava3Test.java - M
room/room-rxjava2/src/main/java/androidx/room/RxRoom.kt - M
room/room-rxjava3/src/main/java/androidx/room/rxjava3/RxRoom.kt
Hash: 52899e0b7ab58364d7467f39dfee82cc3dc2c04d
Date: Wed Mar 12 11:38:37 2025
se...@google.com
Project: platform/frameworks/support
Branch: androidx-main
Author: Daniel Santiago Rivera <
Link:
Use an uninterruptible version of runBlocking
Expand for full commit details
Use an uninterruptible version of runBlocking
As part of Room KMP the internals in Room were migrated to Coroutines and for compatibility reasons blocking functions (APIs and generated code) where migrated to use a bridge that relied on runBlocking. This introduced a behaviour change where if the thread that called runBlocking was interrupted, then runBlocking would throw an InterruptedException. The behaviour in general is not bad since it means work is abandoned faster but it breaks behaviour compatibility as Room never threw this exception before.
To not break existing application and expectations this change adds a runBlockingUninterruptible to be used in Room's bridge that works like runBlocking but ignores thread interruption.
Bug: 342709652
Bug: 400584611
Test: RunBlockingUninterruptibleTest
Change-Id: Ib591225477829e77b51e65a14556d6caddc62222
Files:
- A
room/integration-tests/kotlintestapp/src/androidTest/java/androidx/room/integration/kotlintestapp/test/InterruptionTest.kt - A
room/room-runtime/src/androidInstrumentedTest/kotlin/androidx/room/coroutines/RunBlockingUninterruptibleTest.kt - M
room/room-runtime/src/androidMain/kotlin/androidx/room/InvalidationTracker.android.kt - M
room/room-runtime/src/androidMain/kotlin/androidx/room/RoomDatabase.android.kt - A
room/room-runtime/src/androidMain/kotlin/androidx/room/coroutines/RunBlockingUninterruptible.android.kt - M
room/room-runtime/src/androidMain/kotlin/androidx/room/util/DBUtil.android.kt
Hash: e20fec969cc938655537f87624a6f45e942c370d
Date: Thu Mar 13 10:37:44 2025
Description
Version used: 1.0.0-alpha7
Devices/Android versions reproduced on: Nexus 6 (7.0 NBD92D), Emulator Nexus 4 API 25, and possibly any device
- Situation / Use case
App is using LiveData for network calls.
Activity queries the network observing on a newly created LiveData for that call
There is a background data processing that uses `observeForever` and `removeObserver` to observe ALL network calls generated by any activity.
Once called `removeObserver` from this background data processing the activity currently in foreground (resumed) does not receive the callback.
- Attached is a minimum example of it.
In the example:
The Application instantiates a BackgroundDataProcessing (that calls observeForever/removeObserver) that creates a list of the data and a BackgroundDataObserver that observes to the list of data and logs it.
The MainActivity queries the network LiveData that returns a result 1.5 seconds later. As a piece of automation to demo the bug, the MainActivity will start a new MainActivity in 3 seconds.
The BackgroundDataObserver always receives the value updates and the MainActivity never receives it. If comment out the line `source.removeObserver(this);` on the `BackgroundDataProcessing`, the MainActivity starts receiving those events (but we'll also be leaking memory)
I hope it helps.