{"id":212,"date":"2026-09-27T13:50:00","date_gmt":"2026-09-27T11:50:00","guid":{"rendered":"https:\/\/grindloop.io\/blog\/?p=212"},"modified":"2026-09-27T11:43:41","modified_gmt":"2026-09-27T09:43:41","slug":"android-pagination-race-condition","status":"publish","type":"post","link":"https:\/\/grindloop.ai\/blog\/android-pagination-race-condition\/","title":{"rendered":"Why Fast Scrolling Duplicates Items in Your Paginated List"},"content":{"rendered":"

A paginated list that duplicates items after a fast scroll usually has an Android pagination race condition. The RecyclerView<\/code> or LazyColumn<\/code> showing the list isn’t the problem. The bug is a check-then-act race in the repository underneath. A loadNextPage()<\/code> function reads a currentPage<\/code> counter and fetches that page. It appends the results to a shared list, then increments the counter. Nothing serializes those steps. A fast scroll can trigger a second load before the first one finishes. Both calls can then read the same currentPage<\/code> before either one increments it. The same page gets fetched and appended twice. The next page gets skipped. You don’t need multiple threads for this. The network call suspends. That suspension is enough room for a second coroutine to run the same code.<\/p>\n\n\n

class PagedRepository(private val api: ListApi) {\n\n    private var currentPage = 0\n    private val loadedItems = mutableListOf<Item>()\n\n    suspend fun loadNextPage(): List<Item> {\n        val page = api.fetchPage(currentPage)\n        loadedItems.addAll(page.items)\n        currentPage++\n        return loadedItems\n    }\n}<\/pre>\n\n\n
Bug one: a pagination race condition on currentPage<\/h2>\n\n
api.fetchPage(currentPage)<\/code> reads currentPage<\/code>. currentPage++<\/code> writes it. Between those two lines sits a suspending network call. That’s a real gap in wall-clock time. During it, the dispatcher can run something else. That includes a second loadNextPage()<\/code> call from the same fast scroll. If the second call reads before the first call writes, both coroutines fetch page 0.<\/p>\n\n\n
Coroutine A: reads currentPage \u2192 0, starts fetching page 0\nCoroutine B: reads currentPage \u2192 0, starts fetching page 0 (A hasn't written yet)\nCoroutine A: appends page 0, currentPage++ \u2192 1\nCoroutine B: appends page 0 again, currentPage++ \u2192 2<\/pre>\n\n\n
Page 0’s items are now in loadedItems<\/code> twice. The counter jumped to 2, so page 1 is never fetched. Kotlin’s official concurrency guide<\/a> shows the same kind of bug with a plain counter++<\/code>. Its example runs a hundred coroutines on the multi-threaded Dispatchers.Default<\/code>. The guide says the program is “highly unlikely to ever print” the correct total. The coroutines increment the counter “without any synchronization.” A separate section explains that marking the variable volatile doesn’t help. Read-then-write is two operations, not one. The pagination version adds a suspending call between them, so it can race even on a single thread.<\/p>\n\n
The symptom isn’t hypothetical. Google’s official Paging codelab has an open GitHub issue about duplicate items after scrolling<\/a>. It was filed in June 2021. The trigger in that report differs from the race described here. The symptom is the same. Duplicated or missing rows near page boundaries keep showing up in real Android code, official samples included.<\/p>\n\n
Bug two: an atomic counter still leaves the list unprotected<\/h2>\n\n
Once candidates spot bug one, the usual fix is to make the page counter atomic and stop there.<\/p>\n\n\n
\/\/ Common wrong answer: fixes the counter, not the list\nclass PagedRepository(private val api: ListApi) {\n\n    private val currentPage = AtomicInteger(0)\n    private val loadedItems = mutableListOf<Item>()\n\n    suspend fun loadNextPage(): List<Item> {\n        val page = currentPage.getAndIncrement()\n        val result = api.fetchPage(page)\n        loadedItems.addAll(result.items)\n        return loadedItems\n    }\n}<\/pre>\n\n\n
getAndIncrement()<\/code> does close bug one. Two calls can no longer read the same page number. But the list is still shared without protection. Two fetches now run at once. Page 1 can come back before page 0. When that happens, page 1’s items get appended first and the list is out of order. The risk grows if the repository runs on a multi-threaded dispatcher. mutableListOf()<\/code> returns a plain ArrayList<\/code>. It makes no thread-safety promise under concurrent modification. Two addAll()<\/code> calls racing from different threads can lose items. The function also returns the live list. A caller iterating it while another load appends can hit a ConcurrentModificationException<\/code>. It’s the same shape as bug one in a different spot. One piece of state is protected while the piece next to it stays exposed. A senior answer treats currentPage<\/code> and loadedItems<\/code> as one unit of state that has to be guarded together.<\/p>\n\n
The fix<\/h2>\n\n
The standard fix is a Mutex<\/code> around the whole critical section.<\/p>\n\n\n
class PagedRepository(private val api: ListApi) {\n\n    private val mutex = Mutex()\n    private var currentPage = 0\n    private val loadedItems = mutableListOf<Item>()\n\n    suspend fun loadNextPage(): List<Item> = mutex.withLock {\n        val page = api.fetchPage(currentPage)\n        loadedItems.addAll(page.items)\n        currentPage++\n        loadedItems.toList()\n    }\n}<\/pre>\n\n\n
The Mutex<\/code> wraps the whole read-fetch-append-increment sequence. A second loadNextPage()<\/code> call can’t read currentPage<\/code> until the first call has updated both fields. Pages load one at a time and in order. Returning toList()<\/code> hands callers a snapshot instead of the live list. The Kotlin guide explains why to use Mutex<\/code> over a blocking lock like synchronized<\/code>. In its words, “Mutex.lock() is a suspending function. It does not block a thread.”<\/a> withLock<\/code> wraps the mutex.lock(); try { ... } finally { mutex.unlock() }<\/code> pattern. A coroutine waiting on the mutex suspends and frees its thread. That matters on Android. A blocking lock held across a network call would tie up a dispatcher thread for the whole call.<\/p>\n\n
A quick check confirms both versions. Run two overlapping loadNextPage()<\/code> calls on a single thread, with a fake 100 ms network call, on kotlinx.coroutines 1.9.0. The buggy repository appends page 0 twice. The Mutex<\/code> version loads pages 0 and 1 in order.<\/p>\n\n\n
buggy: [0-0, 0-1, 0-0, 0-1]\nfixed: [0-0, 0-1, 1-0, 1-1]<\/pre>\n\n\n
The rule to remember<\/h2>\n\n
A check-then-act sequence split across a suspending call is a race waiting to happen. Guard the whole sequence and all the state it touches with one Mutex.<\/strong><\/p>\n\n