IllegalStateException thrown when change a MutableState value in the background: "Reading a state that was created after the snapshot was taken or in a snapshot that has not yet been applied" [166486000]

Fixed

Bug

Status Update

No update yet.

Description

ma...@gmail.com

created issue #1

Aug 26, 2020 09:19PM

Version of Gradle Plugin: 4.2.0-alpha07
Version of Gradle: 6.6
Version of Java: 1.8
OS: Android 10

Compose options:

composeOptions {
    kotlinCompilerVersion "1.4.0"
    kotlinCompilerExtensionVersion "0.1.0-dev17"
}

Updating a MutableState value in the backgroung, sometimes I get the following error:

java.lang.IllegalStateException: Reading a state that was created after the snapshot was taken or in a snapshot that has not yet been applied
        at androidx.compose.runtime.snapshots.SnapshotKt.readError(Snapshot.kt:1495)
        at androidx.compose.runtime.snapshots.SnapshotKt.current(Snapshot.kt:1654)
        at androidx.compose.runtime.SnapshotMutableState.setValue(MutableState.kt:499)
        at com.manueldidonna.redhex.inventory.FakeInventory.fetchItems(Test.kt:26)
        at com.manueldidonna.redhex.inventory.TestKt$TestSnapshotCrash$2$1$1.invokeSuspend(Test.kt:60)

Code to reproduce is attached. See @Composable TestSnapshotCrash() It's a simple layout with 3 Tabs and a LazyColumn. Changing the tab, a new list is created in the background and assigned to a mutablestate. That state is used in the lazycolumn. If you change the tab very quickly and many times, the crash should happen.

TestSnapshotCrash.kt

3 KB

Download

Comments

so...@google.com <so...@google.com> Aug 27, 2020 10:00AM

Assigned to ch...@google.com.

ch...@google.com <ch...@google.com> #2Aug 27, 2020 11:07PM

Note to self: the ListView implementation does this as well, let's start there to see how this can be achieved.

ch...@google.com <ch...@google.com> #3Aug 28, 2020 12:53AM

I think I just ran into this as well. I've got a loop that runs some code in a withFrameNanos block, and then runs some code after it before the next iteration. That "after" code relies on layout invalidated by the withFrameNanos block having been performed by the time it runs. This works perfectly in a real app, but in UI tests the loop runs to completion without layout being performed until the end. I almost want a awaitLayout() function to make this dependency more explicit, although I think fixing this issue in tests should be enough. (More discussion in chat thread.)

ch...@google.com <ch...@google.com> Aug 28, 2020 05:58PM

Reassigned to ad...@google.com.

ap...@google.com <ap...@google.com> #4Aug 29, 2020 12:30AM

Marked as fixed.

One blocker for this is that currently the test infra uses an unconfined coroutine dispatcher, which makes it hard to ensure the ordering between withFrameNanos calls and the resumption of the coroutines making them are ordered correctly. We might need to get off unconfined test dispatchers first: b/254115946.

Issue 166486000