remember cache returns stale value when mutable key contents change without reference update

Answer

Compose compares remember keys by calling equals() on the key object; it does not use reference identity or hashCode() alone as the invalidation test. For a data class, equals() compares the declared components. For a plain class without an equals() override, equality is reference equality. For standard collections, equals() compares contents, but an overridden equals() can ignore a mutated field. When old and new keys are equal, remember returns the cached value and the UI can show stale data.

Established behavior and assumptions

Assumed scope: Compose 1.0 through 1.6.x public runtime; later versions may differ. The compiler does not analyze key mutability or warn about insufficient keys. There is no public runtime API to observe or diagnose stale cache hits in production, so correctness is a design-time responsibility. Compiler stability reports can review @Stable and @Immutable annotations, but they do not prove that a key covers every input that affects the cached value.

Steps for this case

1. List every value the cached computation reads. If any value can change while the key's equals() result stays the same, the key is unsafe.
2. Replace the mutable key with an immutable data class or primitive that includes all inputs affecting the output, or create a new key instance when meaningful state changes.
3. If the changing value is Compose snapshot state such as MutableState or StateList, derive the key with derivedStateOf { ... } and pass that result to remember. This invalidates composition when the snapshot state changes without forcing unrelated recomposition.
4. Avoid keyedRemember and other internal runtime APIs; they are not stable across Compose versions.

Verification

Run a Compose test: pass a mutable key to remember, mutate a field not included in equals(), and assert the cached value does not refresh. Then use a key that includes the mutated field or derivedStateOf and assert the value refreshes. Enable compiler reports only to review stability annotations; treat stale-key correctness as a code-review concern.

Missing diagnostic detail

Does the mutable key change through Compose snapshot state, or is it mutated imperatively outside Compose? If it is snapshot state, use derivedStateOf for the key. If it is imperative mutation outside snapshot, derivedStateOf will not see the change; create a new key instance or wrap the state in Compose state.