A pagination cursor describes a position in a particular result set. If the query, result type, or sort changes, that position may no longer mean what it meant before.
Imagine loading page one for “design” in relevance order. The listener then chooses newest. Asking for the next page with the earlier cursor can mix two searches in one list. Even if the server rejects the request, the interface has already created avoidable confusion.
Keep search state together
Store the query, filters, sort, accumulated items, and next cursor as one state object. When a meaningful search setting changes, replace that state with an empty result set. Start a new first request with no previous cursor.
Podnivo documents page.next as the value to pass in the following request's after parameter. Treat the value as opaque. Do not split it, decode its parts, turn it into an offset, or save assumptions about its internal format.
A cache key should include the same search settings. A page cached for show search is not a page cached for episode search, even when the visible query text matches.
Test the interruption points
Change a filter while the second page is loading. Then change it again before the first new page returns. Only results for the final state should remain visible. Combine cursor reset with stale-request protection.
If you restore a search after navigation, restore the complete state or fetch a clean first page. Restoring half of it creates subtle bugs that look like missing catalog data. A small state model is easier to maintain than special fixes for each filter.