An old search request finishes after a newer one. How do you stop it replacing the results?

Say it in 30 seconds

Say it like this (20-30 seconds)

I separate request identity from request timing. MiniTickets debounces text for 250 milliseconds and gives each search input its own TanStack Query key. A late response updates the old key rather than the currently selected search. Cancellation reduces wasted work, but correctness cannot depend on the server stopping. Previous results can remain visible during the transition, so the UI must distinguish pending input from results for the active query.

The deeper answer

Typing creates several possible races: a timer for old text, an in-flight request for old filters, and a slower response arriving out of order. The hook clears the previous debounce timer on every text change, trims the settled text and uses infinite queries with a bounded page size of fifty.

Query keys isolate different inputs. This is stronger than keeping one result variable and assigning every response to it. Abort-on-unmount is enabled, but a cancellation signal cannot reverse database work already finished or guarantee that a remote server stops executing.

The hook deliberately keeps previous data while the next query loads and exposes whether the typed text differs from the debounced query. This avoids flicker, but callers must label transitions honestly and avoid treating placeholder pages as confirmed results for new filters. A useful test delays the old response, changes the input, then verifies that the new search remains selected.

Counter-questions

Does debounce guarantee correct ordering?

No. It prevents many intermediate requests but a request already sent can still finish late. Keyed state or explicit sequence validation must decide which result the UI displays.

What if the server ignores cancellation?

The old request may finish and populate its own cached query. It must not overwrite the data selected by a different search key.

Why retain old results?

It keeps the page stable while loading, at the cost of temporarily showing data for previous inputs. A loading or updating indication and safe pagination controls make that trade-off understandable.

Where in MiniTickets

Read Search pagination, then inspect the web-app piece →.

apps/web/src/features/events/hooks/use-event-search.ts → useEventSearch