Fast switching between tab bars causing creating new tab instead of restoring previous one

[mkowol-n]

Hi,
I found a bug related to navigation. I have an application with bottom nav bar. When i navigate between them using :
navigator.resetRoot(HomeNavTab2, saveState = true, restoreState = true)
everything works fine - the state of each tab is being restored. However, when I rapidly switch between the tabs (akin to "spamming"), the expected state restoration does not occur. Instead, a new screen is generated each time."

[ZacSweers]

Can you link a sample we could reproduce this on? A test would be ideal but even just a sample app that we could manually try. Otherwise there's not much for us to go on here

[mkowol-n]

@ZacSweers sure, here is the repo:
https://github.com/mkowol-n/SlackNavIssue

[mkowol-n]

And here's the video:
https://github.com/slackhq/circuit/assets/81823999/2600f271-8a76-4a02-9763-d0c5f9347bf9

[ZacSweers]

Is this possibly related to #1312? i.e. debouncing issues

[ZacSweers]

Closing as fixed in 0.21.0

[diousk]

Hi @ZacSweers,

I believe issue #1285 is not fully resolved.
While PR #1331 addressed the goTo case, the resetRoot inconsistency still occurs.

Steps to reproduce:

1. Using the test repo at https://github.com/mkowol-n/SlackNavIssue
2. Testing with Circuit version 0.25.0
3. Rapidly switch between tabs (approximately 300ms intervals)

Observed behavior:

• Colors change unexpectedly during rapid tab switching
• Colors eventually restore to correct values when switching tabs at a slower pace

This suggests the resetRoot case may need separate handling.

Could you please verify this behavior and consider reopening the issue?

[diousk]

Hi,

resetRoot() navigation issues: state loss (v0.25.0) and crashes (v0.26.0) during rapid tab switching

(repost from #1930)

Testing has revealed two critical issues with resetRoot() across different Circuit versions:

Circuit v0.25.0:
rememberRetained state is lost during rapid tab switching (~300ms intervals)
Normal navigation retains state correctly
During rapid switching, state resets to initial values

Circuit v0.26.0:
App crashes during rapid tab switching when using resetRoot(saveState = true, restoreState = true)
Error stack trace indicates key registry collision: (though I can't the related circuit code line)

Process: pl.nepapp.slacknavissue, PID: 27021
java.lang.IllegalArgumentException: Key _registry_150d9446-1362-495d-ae1a-67012d6a6140 was used multiple times 
at androidx.compose.runtime.saveable.SaveableStateHolderImpl$SaveableStateProvider$1$1$1.invoke(SaveableStateHolder.kt:90)
at androidx.compose.runtime.saveable.SaveableStateHolderImpl$SaveableStateProvider$1$1$1.invoke(SaveableStateHolder.kt:89)
at androidx.compose.runtime.DisposableEffectImpl.onRemembered(Effects.kt:83)
at androidx.compose.runtime.CompositionImpl$RememberEventDispatcher.dispatchRememberObservers(Composition.kt:1364)
at androidx.compose.runtime.CompositionImpl.applyChangesInLocked(Composition.kt:992)
at androidx.compose.runtime.CompositionImpl.applyLateChanges(Composition.kt:1023)
at androidx.compose.runtime.Recomposer$runRecomposeAndApplyChanges$2$1.invoke(Recomposer.kt:700)
at androidx.compose.runtime.Recomposer$runRecomposeAndApplyChanges$2$1.invoke(Recomposer.kt:585)
at androidx.compose.ui.platform.AndroidUiFrameClock$withFrameNanos$2$callback$1.doFrame(AndroidUiFrameClock.android.kt:41)
at androidx.compose.ui.platform.AndroidUiDispatcher.performFrameDispatch(AndroidUiDispatcher.android.kt:109)
at androidx.compose.ui.platform.AndroidUiDispatcher.access$performFrameDispatch(AndroidUiDispatcher.android.kt:41)
at androidx.compose.ui.platform.AndroidUiDispatcher$dispatchCallback$1.doFrame(AndroidUiDispatcher.android.kt:69)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1561)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1572)
at android.view.Choreographer.doCallbacks(Choreographer.java:1172)
at android.view.Choreographer.doFrame(Choreographer.java:1097)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1546)
at android.os.Handler.handleCallback(Handler.java:995)
at android.os.Handler.dispatchMessage(Handler.java:103)
at android.os.Looper.loopOnce(Looper.java:232)
at android.os.Looper.loop(Looper.java:317)
at android.app.ActivityThread.main(ActivityThread.java:8932)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:591)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:911)
Suppressed: kotlinx.coroutines.internal.DiagnosticCoroutineContextException: [androidx.compose.runtime.PausableMonotonicFrameClock@d1ffd81, androidx.compose.ui.platform.MotionDurationScaleImpl@8a26e26, StandaloneCoroutine{Cancelling}@21caa67, AndroidUiDispatcher@4ca2014]

Steps to reproduce:

1. Clone test repo: https://github.com/diousk/SlackCircuitNavIssue

2. Modify Circuit version in build.gradle.kts:
   Test with v0.25.0 to observe state loss
   Test with v0.26.0 to observe crashes

3. Rapidly switch between tabs (~300ms intervals)
   Note: No instrumental test provided due to complexity of simulating rapid user interactions
   The issue is easily reproducible through manual quick tab switching

[ZacSweers]

@diousk thanks for pasting the longer trace. The lack of circuit anywhere in that trace makes me skeptical that this is really a circuit issue vs something in compose's runtime. Sure, it may be getting tickled by circuit in some way, but even if we reproduced the above in a test (which I still think you should try to create), there's no indication we can fix the underlying compose runtime issue. Please file an issue on the compose issue tracker. If they investigate and find that it's actually a circuit issue I'm happy to revisit.

[ZacSweers]

Someone else filed an issue here: https://issuetracker.google.com/issues/397474792. Will keep an eye on that

[itsandreramon]

They just changed the status to "Won't Fix (Intended Behaviour)"...

[itsandreramon]

Can someone who faced this issue share how you are handling it internally? We are currently debouncing resetRoot calls with a 500ms interval, and it really affects overall responsiveness of our app.

[ZacSweers]

Comment from the issue

Hey! Issue like that is happening when saveableStateHolder.SaveableStateProvider() is composed with the same key twice at any point of time. I would assume that animation infrastructure from your navigation library allows this to happen in some conditions. Like screen A is composed twice - once as part of the animation from A to B and for the second time to display the screen A again as we opened it.

Adding a code like this for each "screen" will help to debug the issue.

DisposableEffect(key) {
    println("$key composed)
    onDispose {
        println("$key disposed)
    }
}

Basically it should never be possible for some key to be composed again before it was disposed previously. As otherwise we can't properly save/restore the state for the screen.

I am pretty confident this issue should be fixed in Circuit, not Compose, so I will close the bug for now. But feel free to comment if you disagree or need more help debugging it. Thanks!

We'll look into it. There might be some spots in our NavigableCircuitContent that could trigger this but off-hand I'm not sure how as it seems like this is a race condition in compose's runtime that can be triggered by fast enough thumbs 🤔