Status Update
No update yet.
Comments
em...@getkeepsafe.com
reemission of the same liveData is racy
se...@google.com
se...@google.com
em...@getkeepsafe.com
@Test
fun raceTest() {
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData)
emitSource(subLiveData) //crashes
}
subject.addObserver().apply {
testScope.advanceUntilIdle()
}
}
se...@google.com
se...@google.com
I actually have a WIP fix for it:
if your case is the one i found (emitting same LiveData multiple times, as shown in #5) you can work around it by adding a dummy transformation.
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData.map {it })
emitSource(subLiveData.map {it} )
}
em...@getkeepsafe.com
Branch: androidx-master-dev
commit af12e75e6b4110f48e44ca121466943909de8f06
Author: Yigit Boyar <yboyar@google.com>
Date: Tue Sep 03 12:58:11 2019
Fix coroutine livedata race condition
This CL fixes a bug in liveData builder where emitting same
LiveData source twice would make it crash because the second
emission registry could possibly happen before first one is
removed as source.
We fix it by using a suspending dispose function. It does feel
a bit hacky but we cannot make DisposableHandle.dispose async
and we do not want to block there. This does not mean that there
is a problem if developer disposes it manually since our emit
functions take care of making sure it disposes (and there is
no other way to add source to the underlying MediatorLiveData)
Bug: 140249349
Test: BuildLiveDataTest#raceTest_*
Change-Id: I0b464c242a583da4669af195cf2504e2adc4de40
M lifecycle/lifecycle-livedata-ktx/api/2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/current.txt
M lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_current.txt
M lifecycle/lifecycle-livedata-ktx/api/restricted_2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/restricted_current.txt
M lifecycle/lifecycle-livedata-ktx/src/main/java/androidx/lifecycle/CoroutineLiveData.kt
M lifecycle/lifecycle-livedata-ktx/src/test/java/androidx/lifecycle/BuildLiveDataTest.kt
se...@google.com
mmm, yeah, seems like there is no information about it there. I'll let you know which build includes it.
em...@getkeepsafe.com
Thank you for all the help.
I'll test it out as soon at it's available and update here.
ap...@google.com
Branch: androidx-main
commit 0bed2f8a6c5c94e5bfcfe7a4e7c13ba1b7ca4166
Author: Sergey Vasilinets <sergeyv@google.com>
Date: Thu Sep 22 16:27:56 2022
Make GreedyScheduler do less "startWork" calls
bug: 248111307
Test: new integration test
Change-Id: I9686ba0810e4444b41ae7d638a6b8db3943da8cb
M work/work-runtime/src/main/java/androidx/work/impl/StartStopToken.kt
M work/integration-tests/testapp/src/main/java/androidx/work/integration/testapp/MainActivity.java
M work/work-runtime/src/main/java/androidx/work/impl/background/greedy/GreedyScheduler.java
A work/integration-tests/testapp/src/main/java/androidx/work/integration/testapp/StressTest.kt
M work/integration-tests/testapp/src/main/res/values/donottranslate-strings.xml
M work/integration-tests/testapp/src/main/res/layout/activity_main.xml
se...@google.com
Build 9098985 and newer has the change.
em...@getkeepsafe.com
I've verified the changes in I9686ba0810e4444b41ae7d638a6b8db3943da8cb improved the performance of the workers being executed. I tested using the
I updated the
Will the changes in I9686ba0810e4444b41ae7d638a6b8db3943da8cb be included in the next alpha build?
I was hoping to update the WorkManager since it's required for compatibility with targeting Android SDK 31.
Thank you for the support.
se...@google.com
Yeah, it will be included in the next release, which is 2.8.0-beta01.
na...@google.com
This bug was linked in a change in the following release(s):
androidx.work:work-runtime:2.8.0-beta01
em...@getkeepsafe.com
Thank you!
eo...@gmail.com
FYI, I get an error in Room DB with this version:
androidx.work:work-runtime:2.8.0-beta01
See error below
# code block
[ERROR] [system.err] /home/eoinzy/workspace/android/myapp/data/build/generated/source/kapt/debug/com/myapp/data/MyAppDatabase_Impl.java:188: error: onCreate(SupportSQLiteDatabase) in <anonymous com.myapp.data.MyAppDatabase_Impl$1> cannot override onCreate(SupportSQLiteDatabase) in Delegate
[ERROR] [system.err] protected void onCreate(SupportSQLiteDatabase _db) {
[ERROR] [system.err] ^
[ERROR] [system.err] attempting to assign weaker access privileges; was public
[ERROR] [system.err] /home/eoinzy/workspace/android/myapp/data/build/generated/source/kapt/debug/com/myapp/data/MyAppDatabase_Impl.java:218: error: onValidateSchema(SupportSQLiteDatabase) in <anonymous com.myapp.data.MyAppDatabase_Impl$1> cannot override onValidateSchema(SupportSQLiteDatabase) in Delegate
[ERROR] [system.err] protected RoomOpenHelper.ValidationResult onValidateSchema(SupportSQLiteDatabase _db) {
[ERROR] [system.err] ^
[ERROR] [system.err] attempting to assign weaker access privileges; was public
[ERROR] [system.err] 2 errors
The issue isn't present in androidx.work:work-runtime:2.8.0-alpha04
da...@google.com
Re room-compiler and room-runtime do you have declared in your project? Can you try using the latest 2.5.0-beta01? I think what is happening is that work-runtime is using a newer version of room-runtime than the one declared in your project but room-compiler is not being updated to match that version as it should be.
eo...@gmail.com
Yes, that's exactly the issue. Using 2.5.0-beta01 seems to fix it. Apologies for the false alarm.
Description
Component used: WorkManager Version 2.8.0-alpha04
Devices/Android versions reproduced on:
Please see demo project:https://github.com/emarc-m/work-manager-oom
Steps to Reproduce:
QUEUE WORKERSbutton to enqueue1_000one-time unique workersTestWMto inspect the progress of the workers runningComparing when the workers gets executed with WorkManager 2.8.0-alpha04 vs version 2.3.4, version 2.3.4 would execute the workers immediately compared to 2.8.0-alpha04. It sometimes look like the WorkManager using 2.8.0-alpha04 is not executing any of the queued workers.
I also noticed that there's more logging like this in 2.8.0-alpha04:
For comparison, the sample project can also be built using WorkManager 2.3.4.
Expected behavior: The work manager should execute workers similar to 2.3.4.
Note: This is related to