SnapshotApplyConflictException retry behavior lacks configurable bounds during recomposition

Conflict detection and automatic restart

Jetpack Compose's snapshot system uses optimistic concurrency: when Snapshot.apply() detects that another snapshot has committed changes to the same State record since the current snapshot was opened, it throws SnapshotApplyConflictException and discards the pending writes. The recomposition machinery catches this exception internally and restarts the affected composition from a fresh snapshot.

Unspecified retry policy

The runtime documentation states only that "the operation must be retried" without defining a maximum retry count, back-off strategy, or timeout for these automatic restarts. In practice this means a hotly contended State object can cause a composable to re-execute indefinitely, amplifying any side-effects that are not properly guarded by remember or LaunchedEffect.

Constraints

• Compose Runtime 1.6.x–1.7.x (androidx.compose.runtime:runtime)
• No public API exists to customize conflict resolution (last-write-wins, manual merge, retry limits)
• Catching SnapshotApplyConflictException directly in app code is discouraged as an internal implementation detail

Given these constraints, how does the recomposition scheduler decide when to stop retrying a composition that repeatedly encounters SnapshotApplyConflictException? Is there an implicit bound tied to frame deadlines, or can a pathological contention scenario livelock the UI thread? What observability hooks (if any) exist to detect excessive retry rates in production?