Choose a term
Search results arrive out of order?
Search input, repeated requests, and stale results
A search field has two separate timing problems: deciding when to send a request and deciding which result may update the screen. Waiting before sending can reduce work, while a response from a previous query can still arrive last. Identify which behavior is wrong before choosing a fix.
Which problem do you have?
Every keystroke starts work that can wait until input pauses.
debounce. Replace the pending action on each edit and act after a quiet interval. The term page includes a timer-controlled comparison of three delayed calls with one debounced call.
See the failure and fixDownload teaching exampleTry the interactive example
An obsolete search keeps using resources after you leave the view.
cooperative cancellation. Propagate cancellation to supported operations and block publication after cancellation. The runnable example includes a dependency that ignores the signal. This is separate from deciding which active query owns the screen.
Several consumers start equivalent requests.
request deduplication. Share the in-flight request or an appropriate cached result. Include every input that changes the result in the key, including user or tenant scope when applicable.
Search results arrive out of order and old results overwrite new ones.
race condition. Reproduce both completion orders and allow only the current request generation to publish. Debounce changes when requests start; it does not establish this ownership rule. The race-condition example also checks a failed latest request.
What to ask the agent to verify
Test a burst of edits, a pause, leaving the view, and an older response finishing after a newer one. Record submissions separately from UI updates. Choose a delay for the actual interaction, and keep immediate feedback such as displaying the typed value independent of delayed network work. Try the debounce page simulation, then run the race-condition and cancellation comparisons independently.
Keep the claim bounded
A debounce timer is not a server rate limit or a guarantee against stale responses. Continuous input can defer trailing-edge execution. If the product needs periodic updates while input continues, choose a different timing policy explicitly.
Sources
Updated and sources checked . How we check content.