Switching a paged search from Kotlin to Compose mixes both result sets. Where would you look?

Answer

Start by tracing the query identity from the search field through the Pager, database query, and remote pagination keys. A single global cursor or unfiltered table can combine data belonging to different searches.

One possible schema

Copy codeArticle(id, title, ...)
SearchResult(queryKey, articleId, position)
SearchCursor(queryKey, nextCursor)

Articles can be shared between searches while membership and ordering remain query-specific. Include relevant filters and account scope in the cache identity. Normalize only inputs the API treats as equivalent.

The UI reads the database through its PagingSource. The RemoteMediator fetches network pages and updates that database; it does not act as a second independent list displayed next to local results.

Refresh handling

Replace membership for the affected query and write its new cursor in one database transaction. Do not clear unrelated cached searches. Append should read the cursor for that same query and commit its data and cursor together. Define what an absent cursor means rather than confusing a first load with the end of pagination.

Follow-up to practise

How would you expose a race? Delay a Kotlin response, switch to Compose, and let the old response finish. Assert that the Compose query displays only its own membership and that cursor updates cannot cross query boundaries.

Reference

Android Developers: Paging from network and database