{"id":772,"date":"2026-10-07T13:55:00","date_gmt":"2026-10-07T11:55:00","guid":{"rendered":"https:\/\/grindloop.io\/blog\/?p=772"},"modified":"2026-10-05T18:23:15","modified_gmt":"2026-10-05T16:23:15","slug":"launchedeffect-stale-value-callback","status":"publish","type":"post","link":"https:\/\/grindloop.ai\/blog\/launchedeffect-stale-value-callback\/","title":{"rendered":"LaunchedEffect Stale Value: Why LaunchedEffect(Unit) Calls an Old Callback"},"content":{"rendered":"

A LaunchedEffect stale value comes from two captures stacked on top of each other. First, LaunchedEffect(Unit)<\/code> starts its coroutine once. The block keeps the onTimeUp<\/code> lambda it saw in the first composition. Recomposition passes in newer lambdas. The running block never sees them. Second, the parent built that lambda as { onSubmit(answer) }<\/code>, with answer<\/code> as a plain String<\/code> parameter. A lambda copies a plain value when it’s created. So the first lambda holds the empty string forever. Before the state was hoisted, answer<\/code> was a delegated mutableStateOf<\/code>. The lambda read it on every call. That hid the first bug. The fix keeps the timer running and refreshes the callback. Read it through rememberUpdatedState(onTimeUp)<\/code> inside the effect. Then key the effect on what should restart it. Here that’s the question ID. Don’t key it on the callback. A new lambda arrives with every keystroke, so the timer would restart each time.<\/p>\n\n

A 60-second question timer that submits an empty answer<\/h2>\n\n

The running example is a timed coding question. The candidate types an answer. After 60 seconds the timer submits whatever is in the box. The screen is stateless, because the answer was hoisted to the ViewModel. Here’s the code a candidate gets handed in a bug-squash round.<\/p>\n\n\n

@Composable\nfun QuestionTimer(seconds: Int, onTimeUp: () -> Unit) {\n    LaunchedEffect(Unit) {\n        delay(seconds * 1_000L)\n        onTimeUp()\n    }\n}\n\n@Composable\nfun QuestionScreen(\n    questionId: String,\n    answer: String,\n    onAnswerChange: (String) -> Unit,\n    onSubmit: (String) -> Unit,\n) {\n    QuestionTimer(seconds = 60, onTimeUp = { onSubmit(answer) })\n    OutlinedTextField(value = answer, onValueChange = onAnswerChange)\n    Button(onClick = { onSubmit(answer) }) { Text(\"Submit\") }\n}<\/pre>\n\n\n
The candidate types “use a Set” and waits. At 60 seconds the ViewModel receives an empty string. The text field shows the answer the whole time. The Submit button sends the right text, too. Only the timer is wrong. Nothing crashes and nothing logs. So the search tends to start in the ViewModel. That’s the wrong layer.<\/p>\n\n
A LaunchedEffect stale value starts with the Unit key<\/h2>\n\n
The Compose side-effects guide<\/a> states the restart rule. The coroutine is canceled and relaunched only when LaunchedEffect<\/code> recomposes with different keys. Unit<\/code> never changes. So the block launched in the first composition is the only one that ever runs.<\/p>\n\n
That block is a lambda. It captured the onTimeUp<\/code> parameter as it was at that moment. QuestionTimer<\/code> does recompose on every keystroke. Each time, it receives a new onTimeUp<\/code>. But that new value goes into a block that LaunchedEffect<\/code> ignores, because the key didn’t change. The running coroutine still holds the first lambda.<\/p>\n\n
The Button doesn’t have this problem. onClick<\/code> is replaced on every recomposition. A tap calls the current one. The timer is the only consumer that outlives a composition.<\/p>\n\n
The same guide warns that LaunchedEffect(true)<\/code> is as suspicious as a while(true)<\/code>. It also gives a rule for variables used in an effect. Each one should be a key or go through rememberUpdatedState<\/code>. This code does neither.<\/p>\n\n
Hoisting the answer turned a state read into a copied String<\/h2>\n\n
A stale first lambda alone isn’t enough to lose the answer. The lambda also has to hold an old value. Before the refactor, the screen owned its state:<\/p>\n\n\n
var answer by rememberSaveable { mutableStateOf(\"\") }\nQuestionTimer(seconds = 60, onTimeUp = { onSubmit(answer) })<\/pre>\n\n\n
That version submitted the right text with the same LaunchedEffect(Unit)<\/code>. answer<\/code> there is a local delegated property. A lambda that uses it captures the delegate. The delegate is the MutableState<\/code> object. Each read of answer<\/code> calls getValue<\/code> at that moment. So the first lambda still read the latest text.<\/p>\n\n
Hoisting changed answer<\/code> into a String<\/code> parameter. A lambda captures a plain val<\/code> by its value. The first lambda now holds \"\"<\/code>. This plain Kotlin program shows the difference. FakeState<\/code> stands in for MutableState<\/code>:<\/p>\n\n\n
import kotlin.reflect.KProperty\n\nclass FakeState(var v: String) {\n    operator fun getValue(t: Any?, p: KProperty<*>) = v\n    operator fun setValue(t: Any?, p: KProperty<*>, n: String) { v = n }\n}\n\nfun main() {\n    var answer by FakeState(\"\")   \/\/ like var answer by mutableStateOf(\"\")\n    val delegated = { answer }    \/\/ captures the delegate\n    val plain = answer            \/\/ like a hoisted answer: String parameter\n    val snapshot = { plain }      \/\/ captures the value \"\"\n    answer = \"use a Set\"\n    println(\"delegated lambda -> \\\"${delegated()}\\\"\")\n    println(\"plain-val lambda -> \\\"${snapshot()}\\\"\")\n}<\/pre>\n\n\n
Compiled with kotlinc<\/code> 2.4.20, it prints this:<\/p>\n\n\n
delegated lambda -> \"use a Set\"\nplain-val lambda -> \"\"<\/pre>\n\n\n
The Unit<\/code> key was wrong from the start. The delegated read covered for it until the refactor moved the state up a level. The same delegated read causes a different Compose bug. See the null check that didn’t save you<\/a>.<\/p>\n\n
Why every keystroke produces a new onTimeUp<\/h2>\n\n
The fix depends on how often onTimeUp<\/code> changes. Strong skipping mode decides that. It’s on by default from Kotlin 2.0.20, per the strong skipping docs<\/a>. The compiler wraps every lambda in a composable in a remember<\/code>. That remember<\/code> is keyed on the lambda’s captures.<\/p>\n\n
{ onSubmit(answer) }<\/code> captures onSubmit<\/code> and answer<\/code>. Both are keys of that hidden remember<\/code>. answer<\/code> changes with each keystroke. So QuestionTimer<\/code> gets a new lambda each time the candidate types. A lambda built from changing state is new whenever that state changes.<\/p>\n\n
That rules out keying the effect on onTimeUp<\/code>. We modeled the effect’s key check and the lambda memo in plain Kotlin with kotlinx.coroutines. Four keystrokes arrived 300 ms apart against a 1-second timer. With the Unit<\/code> key, the model submitted \"\"<\/code> at about 1,000 ms. Keyed on onTimeUp<\/code>, it started the effect five times. It submitted “use a Set” at about 2,200 ms. The timer had moved its deadline with every keystroke. That model reproduces the documented rules. It isn’t Compose itself.<\/p>\n\n
Key the effect on the question and read the callback through rememberUpdatedState<\/h2>\n\n
The fix separates two jobs. A new question should restart the timer. A new callback should only replace the one the timer will call. Each job gets its own tool.<\/p>\n\n\n
@Composable\nfun QuestionTimer(questionId: String, seconds: Int, onTimeUp: () -> Unit) {\n    val currentOnTimeUp by rememberUpdatedState(onTimeUp)\n\n    LaunchedEffect(questionId, seconds) {\n        delay(seconds * 1_000L)\n        currentOnTimeUp()\n    }\n}\n\n\/\/ in QuestionScreen\nQuestionTimer(questionId = questionId, seconds = 60, onTimeUp = { onSubmit(answer) })<\/pre>\n\n\n
This follows the LandingScreen<\/code> sample in the side-effects guide<\/a>. The implementation is small. In SnapshotState.kt<\/code><\/a>, rememberUpdatedState<\/code> remembers one mutableStateOf<\/code>. Then it writes the new value into it on every composition. The effect block captures that one State<\/code> through the by<\/code> delegate. So the call at 60 seconds reads the newest lambda. That lambda carries the newest answer<\/code>.<\/p>\n\n
The delegated read in the old stateful screen did the same job by accident. rememberUpdatedState<\/code> does it on purpose, at the place that needs it. The parent can now pass any lambda it likes, built from plain values or state.<\/p>\n\n
The questionId<\/code> key covers a case the old code also got wrong. Suppose the same QuestionScreen<\/code> stays in composition and shows question 2. With Unit<\/code>, question 2 never gets its own 60 seconds. With questionId<\/code>, the old coroutine is canceled and a fresh timer starts. In the model, the fixed version submitted “use” at about 1,000 ms. That was the text in the box when time ran out. The effect started once.<\/p>\n\n
Android and Compose APIs can’t compile outside an Android project. So this fix hasn’t been run on a device here. Its behavior rests on the guide and the runtime source above.<\/p>\n\n
The explanation that gets credit in a bug-squash round<\/h2>\n\n
This snippet works in a technical round or a bug-squash round. It’s a good “second bug” because the obvious first fix makes it worse. Our Android debugging interview post<\/a> covers how that round is scored. Say it in this order.<\/p>\n\n
    \n
  1. Locate it. The text field and the button are right, so the state is fine. Only the long-lived consumer is wrong. That’s the effect.<\/li>\n
  2. Name the first capture. LaunchedEffect(Unit)<\/code> launches once. Its block holds the onTimeUp<\/code> from the first composition. A new value only matters when a key changes.<\/li>\n
  3. Name the second capture. answer<\/code> is a plain String<\/code> parameter, so that first lambda copied \"\"<\/code>. A delegated mutableStateOf<\/code> would have been read at call time. That’s why it worked before the state was hoisted.<\/li>\n
  4. Reject the obvious fix. Keying on onTimeUp<\/code> restarts the timer on every keystroke. Strong skipping remembers the lambda by its captures. answer<\/code> is one of them.<\/li>\n
  5. Give the fix. Key the effect on questionId<\/code>. Call the callback through rememberUpdatedState<\/code>.<\/li>\n<\/ol>\n\n
    “Use rememberUpdatedState” is the line people memorize. Point 3 goes further. It explains why the bug appeared only after a refactor. That shows you know what a lambda captures.<\/p>\n\n
    Answers that sound right and leave the timer broken<\/h2>\n\n