IssueTracker

After upgrading to kotlin 2.1.0 and bumping remaining dependencies, things seem to work as expected again. EDIT: My bad; was on the wrong branch. Those upgrades did NOT help.

I think I managed to track it down further:

In my Child composable, I'm actually hitting a TODO() statement:

@Composable
fun Child(isLoading: Boolean, items: List<MyDataClass>) {
    // ...
    if (notYetSupported) {
        TODO("This is not yet supported!")
    }
    // ...
}

It would seem that compose swallows this error and throws the above instead which is not very helpful.

The "pending composition has not been applied" error generally means that composition continued despite something in the hierarchy previously throwing an exception. Here it looks like something is continuing a subcomposition unexpectedly, possibly a LazyList.

We should see if we can improve this error messaging. Can you send over a more complete example? The snippets here aren't fleshed out enough to reproduce this swallowing behavior.

Triage notes: It feels like we're very close to having a repro case that we could run internally, but we don't know where the sub-composition is coming from.

Can you send over a more complete example?

Let's hold until we can get a stable repro case from the reporter. Could you send us a ZIP of the project that repros this issue? We'll close this out in a month if we don't get a response.

Bugjuggler: wait 1 month

This took me about an hour to extract but it reproduces the issue for me.

@file:SuppressLint("UnusedMaterialScaffoldPaddingParameter")

package com.example

import android.annotation.SuppressLint
import android.app.Application
import android.os.Bundle
import androidx.activity.ComponentActivity
import androidx.activity.compose.setContent
import androidx.compose.animation.AnimatedVisibility
import androidx.compose.material.MaterialTheme
import androidx.compose.material.Scaffold
import androidx.compose.material.Text
import androidx.compose.runtime.LaunchedEffect
import androidx.compose.runtime.mutableStateOf
import androidx.compose.runtime.remember
import kotlinx.coroutines.delay

class MyApp : Application()

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        setContent {
            MaterialTheme {
                // Scaffold is required!
                Scaffold { _ ->
                    val a = remember { mutableStateOf(true) }
                    val b = remember { mutableStateOf(true) }

                    LaunchedEffect(Unit) {
                        a.value = false
                        delay(50)
                        b.value = false
                    }

                    AnimatedVisibility(visible = a.value) { Text("Hello World") }

                    if (!b.value) {
                        TODO()
                    }
                }
            }
        }
    }
}

Thank you! I was able to reproduce locally. Will look into this. We may eventually dedupe to b/188320755, but this is immensely helpful since we haven't gotten a concrete repro for this bug yet.

One thing to note is that this is definitely related to a race condition. Device speed matters, and a slower device seems more likely to trigger this exception — My aging Pixel XL from 2016 reproduces this very consistently, unlike my local emulator which doesn't demonstrate this issue at all. We had suspected that coroutines were coming into play here, so a lot of pieces are starting to come together.

Correction: The emulator I was using had animations disabled. This seems to reproduce very consistently across devices.

It looks like our exception handling logic is try/catching Exception instead of Throwable. TODO() is breaking things because it throws a NotImplementedError, which isn't caught by our error handler and doesn't cancel pending recompositions. We'll update our code to include Errors and generic Throwable classes. It's not immediately obvious if this will fix other occurrences of this exception since we don't have other reproduction cases.

Project: platform/frameworks/support
Branch: androidx-main
Author: Andrew Bailey <anbailey@google.com>
Link:      https://android-review.googlesource.com/3443779

Fix Throwables causing unapplied composition error

Fix Throwables causing unapplied composition error 
 
The error handling logic in the Recomposer was set up to catch 
throwables that extended from Exception, which excluded Errors (like 
NotImplementedError, error(""), StackOverflowError, etc.) and 
user-defined exceptions that extend directly from Throwable. This CL 
updates the relevant pathways to switch over all Throwables. 
 
This resolves at least one pathway that leads to a "Pending composition 
has not been applied." runtime error. It's not immediately clear if this 
accounts for all of the reports since we only have one known 
reproduction case right now. 
 
Test: Manually run repro case in the linked bug 
Fixes: b/382094412 
Relnote: """ 
    Fixes an issue where raising a throwable during composition that 
    does not extend from Exception may lead to a 'Pending composition 
    has not been applied' error. 
    """ 
Change-Id: I356be5d99df41138be790275807544b2d717050c

Compose does not ensure repeatable read consistency across a sub-composition boundary (that is we do not guarantee that a mutable value read by the parent composition will be the same value read by the sub-composition).

However, as I noted above, we will be changing the runtime to avoid recomposing sub-compositions that have been detected in the parent composition as being removed, point (2) in comment #3 above. This change should land this week. This changes requires an API change to how composition interacts with the recomposer so it is not a candidate for cherry-picks to earlier versions and, as it is a behavior change, requires going though the our normal release cycle to ensure it doesn't regress behavior or performance. We will also be landing, as a separate change, a solution to (1) above, which will also require API changes. (1) is riskier and we are doing it as a separate change as (2) is strictly an improvement over current behavior (much less likely to cause a regression) than (1) and can land independently of (1).

These two changes will change the rules so that the assumption how data dependencies are handled across sub-composition boundaries, as is implied by the assert above in comment #1, will be honored for composition scheduled by the recomposer. However, as composition can occur at anytime for a sub-composition, there are cases where the assert above will throw and assuming it will always being true should not be relied on. These changes make it so the recomposer, at least, will not introduce violations to this assumption, and will require explicit calls to setContent of a Composition to be violated. When and why setContent is called is in the hands to the code that created the composition, not the recomposer, or the rest of the runtime, which is why we cannot guarantee the assert assumption will always hold.

Theses changes will not ensure repeatable read consistency across a sub-composition boundary, but they will make it much easier for code to avoid requiring it by avoiding recomposing code that is being removed. Because repeatable read consistency is not guaranteed it is recommended that code not rely on it and avoid it by avoiding repeating reads as shown in the examples in comment #5.

I am sorry if my calling this a feature request above implied a lack of priority. We are treating this change as a high priority change for the next feature release. As it requires an API change and a change to the rules of how composition works I think of it as a feature request but will leave it marked as a bug type to avoid confusion.

As Ben and I found a relatively fast and safe way to fix this that didn't involve an API changes, we have started the process to cherry-pick this to earlier releases.

Which version is this in / going to be in?

This issue will be updated when it lands in a stable release.

I could not reproduce the crash above with 1.6.0-alpha01

The steps I took where:

1. Created a new android project using Android Studio Giraffe | 2022.3.1 RC 1
2. Replaced Greeting with the code in #1 (fixing the imports)
3. Ran the program
4. Pressed the button (crash reproduced)
5. Added the line implementation("androidx.compose.runtime:runtime:1.6.0-alpha01") to the dependencies
6. Update the compile sdk to 34.
7. Sync'ed gradle
8. Ran the program
9. Pressed the button (no crash)

Note the above fix is only a partial fix. There are cases that will continue to violate the implied constraint until the second part of the fix lands (explained above).

Also note that this doesn't guarantee the constraint implied by the assert will always hold, only that the runtime will try to avoid recomposing sub-compositions that might be exposed to the constraint. Any use of sub-composition can violate this constraint as the value might change between the time the main composition composes and the sub-composition composes and before the main composition can be recomposed to remove the sub-composition.

If you require consistency between a composition and its subcomposition you need to capture the state as #5, above. This change just avoids a common case would violate this constraint.