Loading challenge...
Out-of-Order Search
Beat a search whose short queries resolve slower — assert the final query wins, not a stale response
What you will learn
- Recognize race conditions caused by uncancelled overlapping async requests
- Use response-matched waits (waitForResponse) instead of fixed timeouts to avoid stale data
- Assert on a state attribute (data-query) that proves the rendered results belong to the final input
Out-of-Order Search
Each keystroke fires a request that is never cancelled — and the backend answers short queries SLOWER than long ones, so stale responses can overwrite fresh ones
Type into the box and every character fires a new request to /api/lab/search. The server delay is inversely proportional to the query length, so an early short query can resolve after a later long one and clobber the list.
A naive test that just waits a fixed time then reads the results will sometimes see stale data. Your job is to assert that the displayed results actually match the final query.
Search
Results render in whatever order responses arrive
showing results for:
- No results yet — start typing.
Testing Tips
Automation hints
- ✓ A naive script that fills
#search-inputthen waits a fixed timeout often reads stale results — the early short-query response lands last and overwrites the final list - ✓ The robust fix is to wait for the correct response:
page.waitForResponse(r => r.url().includes(finalQuery))before asserting, or abort/cancel stale in-flight requests in the app - ✓ Always assert the displayed query matches what you typed — check
#search-results[data-query]equals the final query, not just that any rows exist - ✓ Each row carries a stable
data-resultid — count[data-result]for result presence and read its text for ordering checks - ✓
#search-statusflips betweentyping…andshowing results for: <q>— use it as a settle signal, but never trust it overdata-query
