Crash during rapid tab switching with resetRoot(saveState = true, restoreState = true)

[diousk]

Hi,

I've encountered an issue when calling resetRoot(saveState = true, restoreState = true).

In Circuit version 0.25.0,
I've discovered that issue #1285 appears to not be fully resolved for the resetRoot case, despite PR #1331 fixing the goTo scenario. The resetRoot() problem still exists.

In Circuit version 0.26.0,
The app crashes when rapid switching with calling resetRoot(saveState = true, restoreState = true)

java.lang.IllegalArgumentException: 
Key _registry_79092151-9d0e-4199-9949-9ede4f51285b 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)

Actually, I've left a comment on #1285 to request for re-open that issue but with no response.
So I decide to create a new one.

The Issue:

The issue occurs where rememberRetained state is lost during rapid tab switching (around 300ms intervals) when calling resetRoot(saveState = true, restoreState = true).

Example:

var isLoading by rememberRetained { mutableStateOf(true) }
// after some operation, I change `isLoading` to false
// but on rapid resetRoot(Screen, saveState = true, restoreState = true), 
// the state is lost and `isLoading` is reset to true

Current behavior: (Circuit v0.25.0)

When switching tabs at normal speed: retained state restored correctly
During rapid tab switching: retained state resets to initial value
(e.g., if isLoading was set to false, it resets back to true)

Current behavior: (Circuit v0.26.0)
The app just crashes when rapid tab switching.

You can reproduce this using the test repo:
https://github.com/diousk/SlackCircuitNavIssue
with changing the version of Circuit in build.gradle.kts file

[ZacSweers]

I'll reopen that one to consolidate context, sorry we missed your comment (I was on vacation). If you wouldn't mind adding the above details. It would be helpful if you could minimize this into a failing unit/instrumentation test as it sounds a bit vague to just say "fast" and the error trace you linked doesn't mention any circuit APIs (perhaps you cut off the trace too much?)