{"id":763,"date":"2026-10-06T14:05:00","date_gmt":"2026-10-06T12:05:00","guid":{"rendered":"https:\/\/grindloop.io\/blog\/?p=763"},"modified":"2026-10-05T14:06:06","modified_gmt":"2026-10-05T12:06:06","slug":"stateflow-not-emitting-mutablelist","status":"publish","type":"post","link":"https:\/\/grindloop.ai\/blog\/stateflow-not-emitting-mutablelist\/","title":{"rendered":"StateFlow Not Emitting When You Add to a MutableList Inside update {}"},"content":{"rendered":"

StateFlow not emitting after you add to a list means the new state equals the old one. Two causes stack up. First, MutableStateFlow<\/code> compares states with equals()<\/code>, not by reference. Your code adds the item to a MutableList<\/code> in place. Then it calls copy()<\/code>. But copy()<\/code> is shallow, so the old state and the new state share one list. Both now hold the new item. So they compare equal. StateFlow skips the emission. Second, update {}<\/code> is a retry loop. Under contention it can run your lambda more than once. A lambda that mutates a shared list adds the item again on every retry. The list isn’t thread-safe either. So you get duplicates, lost items and even null entries. The fix is an immutable state. Declare val items: List<CartItem><\/code> and build a new list inside update<\/code>, with state.copy(items = state.items + item)<\/code>. The lambda then has no side effects. Every add emits. A retry is harmless.<\/p>\n\n

A cart that shows the headphones but never the free sticker<\/h2>\n\n

The running example is a shopping cart ViewModel. It’s the shape you’d write in a live-coding round. The state is a data class with a list and a total. add()<\/code> uses update<\/code>, because that’s the thread-safe way to change a MutableStateFlow<\/code>. To compile it outside Android, ViewModel<\/code> is a plain stand-in class. Nothing in the bug depends on androidx.lifecycle<\/code>.<\/p>\n\n\n

import kotlinx.coroutines.*\nimport kotlinx.coroutines.flow.*\n\nopen class ViewModel \/\/ stand-in for androidx.lifecycle.ViewModel\n\ndata class CartItem(val sku: String, val priceCents: Int)\n\ndata class CartUiState(\n    val items: MutableList<CartItem> = mutableListOf(),\n    val totalCents: Int = 0,\n)\n\nclass CartViewModel : ViewModel() {\n    private val _uiState = MutableStateFlow(CartUiState())\n    val uiState: StateFlow<CartUiState> = _uiState.asStateFlow()\n\n    fun add(item: CartItem) {\n        _uiState.update { state ->\n            state.items.add(item)\n            state.copy(items = state.items, totalCents = state.totalCents + item.priceCents)\n        }\n    }\n}\n\nfun main() = runBlocking {\n    val vm = CartViewModel()\n    val first = vm.uiState.value\n    val job = launch(Dispatchers.Unconfined) {\n        vm.uiState.collect { println(\"emitted: ${it.items.map { i -> i.sku }} total=${it.totalCents}\") }\n    }\n    vm.add(CartItem(\"headphones\", 4999))\n    vm.add(CartItem(\"free-sticker\", 0))\n    println(\"state now: ${vm.uiState.value.items.map { it.sku }}\")\n    println(\"initial state object now holds: ${first.items.map { it.sku }}\")\n    job.cancel()\n}<\/pre>\n\n\n
Compiled with kotlinc<\/code> 2.4.20 against kotlinx.coroutines 1.11.0, it prints this:<\/p>\n\n\n
emitted: [] total=0\nemitted: [headphones] total=4999\nstate now: [headphones, free-sticker]\ninitial state object now holds: [headphones, free-sticker]<\/pre>\n\n\n
The headphones emit. The free sticker never does. Yet the state holds it. A screen collecting this flow would show one item while the ViewModel holds two. The bug looks random in a real app. Any add that changes the total emits. An add with a price of zero doesn’t. The last line explains it. The very first state object, the one that emitted an empty list, now holds both items.<\/p>\n\n
StateFlow not emitting comes from equals and one shared list<\/h2>\n\n
The StateFlow API docs<\/a> describe the rule. Values are conflated with an Any.equals<\/code> comparison, much like distinctUntilChanged<\/code>. A new value equal to the previous one isn’t emitted to collectors. The source shows where it happens. In StateFlow.kt<\/code><\/a>, updateState<\/code> checks oldState == newState<\/code>. If that’s true, it returns without storing or notifying anything.<\/p>\n\n
So the question is why the old and new states are equal. The Kotlin data class docs<\/a> answer it. copy()<\/code> makes a shallow copy. It doesn’t copy properties recursively, so references to other objects are shared. Walk the free-sticker call through that:<\/p>\n\n
    \n
  1. update<\/code> reads the current state. Call it S1. Its items<\/code> is list L, holding the headphones.<\/li>\n
  2. The lambda adds the sticker to L. S1 changes in place. Its list now has two items.<\/li>\n
  3. copy()<\/code> builds S2 with the same list L and the same total, 4999.<\/li>\n
  4. Data class equals()<\/code> compares S1 and S2 field by field. Both point at L. Both totals are 4999. So S1 equals S2. StateFlow skips the emission.<\/li>\n<\/ol>\n\n
    The headphones emitted only because the total changed from 0 to 4999. Even there, the two lists compared equal. The previously emitted state had already gained the item in step 2. That’s also why the first state object ends up with both items. Every state this ViewModel ever produced points at the same list.<\/p>\n\n
    update {} can run your lambda more than once<\/h2>\n\n
    The second cause stays hidden until two threads add at once. update<\/code> isn’t a lock. The update<\/code> docs<\/a> say it changes the value atomically. They also warn that the function may be evaluated multiple times if the value is being updated concurrently. The source shows why. update<\/code> is a while (true)<\/code> loop. It reads the value and runs your function. Then it tries compareAndSet<\/code> from the value it read to the new one. If another thread changed the value in between, the swap fails and the loop runs your function again.<\/p>\n\n
    A retry is safe only when the function has no side effects. This lambda has one. It adds to a list that every state shares. Here’s the same CartViewModel<\/code> hit by 8 coroutines on Dispatchers.Default<\/code>, each adding 10,000 items at 100 cents:<\/p>\n\n\n
    fun main() = runBlocking {\n    val vm = CartViewModel()\n    withContext(Dispatchers.Default) {\n        repeat(8) { t ->\n            launch { repeat(10_000) { i -> vm.add(CartItem(\"sku-$t-$i\", 100)) } }\n        }\n    }\n    val state = vm.uiState.value\n    val distinct = state.items.filterNotNull().map { it.sku }.toSet().size\n    println(\"distinct=$distinct items=${state.items.size} nulls=${state.items.count { it == null }} total=${state.totalCents}\")\n}<\/pre>\n\n\n\n
    distinct=76320 items=146543 nulls=241 total=8000000\ndistinct=77097 items=135089 nulls=134 total=8000000\ndistinct=76230 items=141992 nulls=32 total=8000000<\/pre>\n\n\n
    Those are three runs. The exact numbers change every time. The total is right in all three, at 80,000 adds times 100 cents. The total is computed from the state the lambda receives, so a retry recomputes it correctly. The list is wrong in three ways. It holds far more than 80,000 entries, because every retry added its item again. Fewer than 80,000 SKUs are distinct, so some adds were lost. The ArrayList<\/code> docs<\/a> say the class isn’t synchronized. Concurrent add<\/code> calls overwrite each other. The list is declared MutableList<CartItem><\/code>, yet it holds nulls. That’s a sign the concurrent adds corrupted its internal array.<\/p>\n\n
    The two causes interact. Without the total, every state would compare equal. Then compareAndSet<\/code> never fails. Nothing retries. You’d still lose items to the ArrayList<\/code> race. The duplicates appear once some field changes on every add.<\/p>\n\n
    Build a new list inside update and keep the lambda pure<\/h2>\n\n
    The fix removes the shared mutable list. The state holds a read-only List<\/code>. The lambda builds the next state from the current one and touches nothing else.<\/p>\n\n\n
    data class CartUiState(\n    val items: List<CartItem> = emptyList(),\n    val totalCents: Int = 0,\n)\n\nclass CartViewModel : ViewModel() {\n    private val _uiState = MutableStateFlow(CartUiState())\n    val uiState: StateFlow<CartUiState> = _uiState.asStateFlow()\n\n    fun add(item: CartItem) {\n        _uiState.update { state ->\n            state.copy(items = state.items + item, totalCents = state.totalCents + item.priceCents)\n        }\n    }\n}<\/pre>\n\n\n
    With the same imports and main<\/code>, the output changes:<\/p>\n\n\n
    emitted: [] total=0\nemitted: [headphones] total=4999\nemitted: [headphones, free-sticker] total=4999\nstate now: [headphones, free-sticker]\ninitial state object now holds: []<\/pre>\n\n\n
    The sticker emits. The first state still holds an empty list. state.items + item<\/code> returns a new list. The stdlib plus<\/code> docs<\/a> describe it as a list of the original elements followed by the new one. So the old state keeps its old list. The two states differ. In the contended test, 8 coroutines added 2,000 items each. Every run ended with exactly 16,000 items and the right total. A counter inside the lambda showed between 66,000 and 86,000 calls across three runs. So update<\/code> retried tens of thousands of times. Each retry threw away a list it had built. Nothing else changed, so the retries were harmless.<\/p>\n\n
    Two details make this hold up. First, the type. List<CartItem><\/code> has no add<\/code>, so nobody can mutate a state by accident. Second, the cost. Each add copies the list. For a cart, that’s nothing. For a list of thousands of rows updated many times a second, the copy can start to matter. Measure it before you change the data structure.<\/p>\n\n
    Compose sits downstream of all this. collectAsStateWithLifecycle()<\/code> can only show what the flow emits. The Compose state guide<\/a> warns against ArrayList<\/code> or mutableListOf()<\/code> as state. Users see stale or incorrect data. It recommends an observable holder with an immutable listOf()<\/code>. The fixed CartUiState<\/code> follows that rule.<\/p>\n\n
    What to say when the interviewer asks why the sticker is missing<\/h2>\n\n
    This snippet fits a live-coding round or a bug-squash round. The race is the classic second bug, the one left after the first fix goes green. Our Android debugging interview post<\/a> covers how that round is scored. Here’s the explanation to give.<\/p>\n\n
      \n
    1. Name the comparison. StateFlow drops a value that equals()<\/code> the current one. It doesn’t compare references. So a new CartUiState<\/code> object isn’t enough.<\/li>\n
    2. Explain the equality. copy()<\/code> is shallow. The old and new states share one list. The in-place add<\/code> already changed the old state. When the total doesn’t move, the two are equal and nothing emits.<\/li>\n
    3. Name the second bug. update<\/code> is a compare-and-set loop that may rerun its lambda. A side effect in it repeats on each retry. ArrayList<\/code> isn’t thread-safe either. So concurrent adds produce duplicates, lost items and nulls.<\/li>\n
    4. Give the fix. Use an immutable List<\/code> in the state. Build the next list inside update<\/code> with state.items + item<\/code>. The lambda becomes a pure function of the current state, so retries are safe.<\/li>\n<\/ol>\n\n
      The missing emission is the bug you can see on screen. The retry inside update<\/code> only shows up under load, so naming it unprompted is the stronger signal. The same pipeline has another quiet failure, in how a derived flow is shared. See why a combined StateFlow shows stale data<\/a>.<\/p>\n\n
      Three fixes candidates reach for that leave a bug behind<\/h2>\n\n
      Each of these ran against the cart example with the same compiler and library versions.<\/p>\n\n
        \n
      • Switching to MutableSharedFlow(replay = 1)<\/code> removes the equality check. So the free sticker does emit. But the list is still shared. After the second add, the first emitted state held both items. Any code comparing an old state with a new one sees no difference. You also give up update<\/code> and its atomic swap.<\/li>\n
      • Wrapping update<\/code> in a Mutex<\/code> stops the race. No retry ever happens. The emission bug stays. The run printed the headphones and never the sticker.<\/li>\n
      • Building a new list but assigning it with _uiState.value = _uiState.value.copy(...)<\/code> fixes the emission. This emits every add on one thread. But it reads and writes the value in two steps. We ran it twice with 8 coroutines adding 2,000 items each. The cart ended with 3,719 and then 3,998 items out of 16,000. The other adds were overwritten. That’s the race update<\/code> exists to prevent.<\/li>\n<\/ul>\n\n
        Each of these leaves one of the two causes in place. The fix needs both halves. The state must be impossible to change in place. The change must go through update<\/code>.<\/p>\n","protected":false},"excerpt":{"rendered":"
        StateFlow not emitting after you add to a MutableList? copy() shares the list so states compare equal, and update {} retries repeat the add. Repro and fix.<\/p>\n","protected":false},"author":2,"featured_media":765,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"StateFlow Not Emitting When You Add to a MutableList Inside update {}","rank_math_description":"StateFlow not emitting after you add to a MutableList? copy() shares the list so states compare equal, and update {} retries repeat the add. Repro and fix.","rank_math_focus_keyword":"stateflow not emitting","footnotes":""},"categories":[9,3],"tags":[15,70,13,16,12,14,45],"class_list":["post-763","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-bug-squash","category-coroutines","tag-android","tag-concurrency","tag-coroutines","tag-interview-prep","tag-kotlin","tag-stateflow","tag-technical-interview"],"_links":{"self":[{"href":"https:\/\/grindloop.ai\/blog\/wp-json\/wp\/v2\/posts\/763","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/grindloop.ai\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/grindloop.ai\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/grindloop.ai\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/grindloop.ai\/blog\/wp-json\/wp\/v2\/comments?post=763"}],"version-history":[{"count":1,"href":"https:\/\/grindloop.ai\/blog\/wp-json\/wp\/v2\/posts\/763\/revisions"}],"predecessor-version":[{"id":764,"href":"https:\/\/grindloop.ai\/blog\/wp-json\/wp\/v2\/posts\/763\/revisions\/764"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/grindloop.ai\/blog\/wp-json\/wp\/v2\/media\/765"}],"wp:attachment":[{"href":"https:\/\/grindloop.ai\/blog\/wp-json\/wp\/v2\/media?parent=763"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/grindloop.ai\/blog\/wp-json\/wp\/v2\/categories?post=763"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/grindloop.ai\/blog\/wp-json\/wp\/v2\/tags?post=763"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}