IssueTracker

it won't make it to the next version (the built was already cut for the postponed Android11 launch). Should go out the version after :) but meanwhile, you can try using the snapshot (androidx.dev). we don't really play w/ this codebase much so it should be fairly stable :)

I'm getting this same java.lang.IllegalStateException: Cancel call cannot happen without a maybeRun exception every so often (on devices running production, but not locally during debug).

Is there some other way I can work around this (besides taking a dependency on androidx.dev)?

I have two StateFlows (The values change based on logic in background Workers)

private val _activeCycleIdFlow = MutableStateFlow(0)
private val _latestCycleIdFlow = MutableStateFlow(0)

whose results are combined

val newCycleAvailable: Flow<Boolean>
  get() = _activeCycleIdFlow.combine(_latestCycleIdFlow) { a, b -> a != b }

Which is used as follows:

val newCycle: LiveData<Boolean> = cycleRepo.newCycleAvailable.asLiveData()

unfortunately i cannot think of an easy way to work around this besides copying the asLiveData code and removing the exception (it won't hurt actually, it is just consistency check to find such bugs).

Depending on which version you are in, depending on androidx.dev may not be too bad as it fairly stable library. If I were you, i would just pull in my own asLiveData :(

Comment #12: Thanks, I'm going to do that.

Comment #12: So if I understood you correctly, I should just ignore java.lang.IllegalStateException before emitting? There isn't much else to asLiveData.

  @InternalCoroutinesApi
  val newCycle: LiveData<Boolean> = liveData {
        cycleRepo.newCycleAvailable
                .catch {
                    // ignore IllegalStateException and log cause
                }
                .collect {
                    emit(it)
                }

    }

catching exceptions thrown from the pipeline is not a great idea as it might leave it in an inconsistent state (because the code that is intended to run after it won't run). It is better to just copy it w/o the check

comment #15:

Okay, I'm clearly missing something; when I open the code (ctrl+click) for asLiveData (from FlowLiveData.kt), it seems very simple, and I don't see any checks. This is it:

@JvmOverloads
fun <T> Flow<T>.asLiveData(
    context: CoroutineContext = EmptyCoroutineContext,
    timeoutInMs: Long = DEFAULT_TIMEOUT
): LiveData<T> = liveData(context, timeoutInMs) {
    collect {
        emit(it)
    }
}

If I do the following am I not just duplicating the above?

val newCycle: LiveData<Boolean> = liveData {
        cycleRepo.newCycleAvailable
                .collect {
                    emit(it)
                }
    }

sorry the check is in the liveData function.

https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:lifecycle/lifecycle-livedata-ktx/src/main/java/androidx/lifecycle/CoroutineLiveData.kt;l=183

so you need to copy a couple :(

comment #17:

Thanks. That makes more sense to me :)

Comment #17: Sorry to be a pain. I considered depending on a snapshot (if only for a few weeks) to be the lesser of two evils.

So I changed my code back to using .asLiveData() and modified my gradle scripts to include

allprojects {
  repositories {
    ...
    maven { url 'https://androidx.dev/snapshots/builds/6603247/artifacts/repository' }
  }
}

and

def lifecycle_version = "2.3.0-SNAPSHOT"

I compared the CoroutineLiveData.kt for the different versions (alpha4, snapshot) and they are identical. I take it the fix is elsewhere? Is it publicly available? Sorry I don't normally use snapshot builds of libraries.

yea the fix is actually in core.

https://android-review.googlesource.com/c/platform/frameworks/support/+/1323278/7/lifecycle/lifecycle-livedata-core/src/main/java/androidx/lifecycle/LiveData.java

i was recommending just removing the check for now, it won't hurt as it is more of a state check to catch these bugs.

but i'm thinking, maybe you should just move to snapshot. also a new version is coming w/ the fix soon (i think next week)

#20,

Thank you.