SnapshotApplyConflictException retry behavior lacks configurable bounds during recomposition

Answer to the Core Question

The recomposer does not expose a configurable retry limit. It relies on the frame‑callback loop: each composition must finish before the next VSYNC. If a SnapshotApplyConflictException occurs, the composition is retried immediately, but the next attempt is only scheduled after the current frame’s deadline. In practice this means the implicit bound is roughly one retry per frame (≈60 retries per second on a 60 Hz display). If contention is so high that the UI thread can’t finish a recomposition before the next deadline, the scheduler keeps restarting the same composition every frame, effectively saturating the UI thread until contention subsides or the process is killed.

Confirmed Facts

• Compose Runtime 1.6.x–1.7.x uses frame‑deadline abort as an implicit bound.
• There is no public API to set retry counts, back‑off, or timeouts.
• Repeated SnapshotApplyConflictException can lead to a livelock that consumes the UI thread.
• Observability is limited to runtime tracing and frame‑callback monitoring; no dedicated retry counter is exposed.

Observing Excessive Retry Rates in Production

1. Enable Compose Runtime Tracing

   adb shell setprop debug.tracing.enable 1
   adb shell am start -n your.package/.YourActivity
   adb shell setprop debug.tracing.enable 0
   adb pull /data/local/tracing/trace.txt
   

   Look for repeated Recomposer.runRecomposeAndApplyChanges spans that occur back‑to‑back without intervening FrameCallback boundaries.

2. Monitor Frame Timestamps

   adb shell top -m 10 -t
   

   High CPU usage on the main thread during a contention test indicates the scheduler is retrying every frame.

3. In‑App Counter (for debugging builds)

   LaunchedEffect(Unit) {
       var counter = 0
       snapshotFlow { myState.value }
           .onEach { counter++ }
           .launchIn(this)
       Log.d("ComposeRetry", "Recompositions: $counter")
   }
   

   When the counter stops growing after a few seconds, the frame deadline bound is being hit.

What to Do If Livelock Is Observed

• Ensure state mutations that could trigger conflicts are isolated in remember, derivedStateOf, or LaunchedEffect blocks.
• Reduce mutation frequency from background threads or batch updates.
• Consider using MutableState only for UI‑visible data; use plain objects for heavy logic.

Missing Diagnostic Detail

To refine the recommendation, it would help to know the device’s refresh rate (e.g., 60 Hz vs 90 Hz). The implicit retry bound scales with the frame period, so a higher refresh rate allows more retries per second before saturating the UI thread.