IssueTracker

Yigit, do you have time to fix it?

reemission of the same liveData is racy

yea i'll take it.

Thanks for the detailed analysis. This may not be an issue anymore since we've started using Main.immediate there but I' not sure; I'll try to create a test case.

just emitting same live data reproduces the issue.

    @Test
    fun raceTest() {
        val subLiveData = MutableLiveData(1)
        val subject = liveData(testScope.coroutineContext) {
            emitSource(subLiveData)
            emitSource(subLiveData) //crashes
        }
        subject.addObserver().apply {
            testScope.advanceUntilIdle()
        }
    }

With 2.2.0-alpha04 (that use Main.immediate), the issue seems to be still there (I tested it by calling emitSource() twice, like your test case)

yea sorry immediate does not fix it.
I actually have a WIP fix for it:
https://android-review.googlesource.com/c/platform/frameworks/support/+/1112186

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} )
        }

Project: platform/frameworks/support
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

https://android-review.googlesource.com/1112186
https://goto.google.com/android-sha1/af12e75e6b4110f48e44ca121466943909de8f06

Hi, i am also facing this issue after we dismiss a DialogFragment, the callback comes in the onPrepareOptionsMenu(), which is causing the issues for me.
Any idea on when it will be fixed?

Hello, any estimate please?

Facing a similar kind of issue when scrolling the fragments using a ViewPager.

https://issuetracker.google.com/issues/267677504

Can you update regarding any progress on this issue.

I wonder if the new SearchBar has this issue:
https://material.io/blog/android-stable-release-1-8-0

Project: platform/frameworks/support
Branch: androidx-main

commit 50f098644adc703ae218b0b7e999629f516a0241
Author: sanura <sanura@google.com>
Date:   Thu Mar 02 00:11:35 2023

    Add check to only invalidate options menu when contributing menu items
   
    FragmentManager previously appropriately only added
    a MenuProvider when the host is a MenuHost **and**
    we are at the root fragment that is providing the
    menu items. This behavior should be mirrored when
    removing a MenuProvider as well, so that only
    components that directly contribute menu items will
    invalidate the options menu.
   
    Bug: 244336571
    Test: all tests pass
    Change-Id: I9404ee9fcc9ce6b80d70a93bea720fe4ccf583a0

M       fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentContainerInflatedFragmentTest.kt
M       fragment/fragment/src/androidTest/java/androidx/fragment/app/OptionsMenuFragmentTest.kt
M       fragment/fragment/src/androidTest/java/androidx/fragment/app/test/FragmentTestActivity.kt
M       fragment/fragment/src/main/java/androidx/fragment/app/FragmentActivity.java
M       fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java

https://android-review.googlesource.com/2465169

@13 Fixed when? On which version of which dependency?
Please show what to write on gradle file.

@15 I've noticed I can avoid using the fragment dependency and still work fine with fragments. How come?
It's part of the material dependency, perhaps?

@17 What if I don't use this dependency (probably imported automatically by material dependency) ? Use it, still?

@17 I wanted to try what you wrote on the sample I've provided (after I remove my workaround), and for some reason it doesn't let me.
It says "Duplicate class found".
The IDE doesn't provide any useful explanation of what is the class that is duplicated and what to do about it.
Please help.

@20 Not 1.6.0-alpha07 ?

@22 So it's fixed on both. OK