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-input then 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-result id — count [data-result] for result presence and read its text for ordering checks
✓ #search-status flips between typing… and showing results for: <q> — use it as a settle signal, but never trust it over data-query

Related Challenges

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

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.

Testing Tips

Automation hints

✓ A naive script that fills #search-input then 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-result id — count [data-result] for result presence and read its text for ordering checks
✓ #search-status flips between typing… and showing results for: <q> — use it as a settle signal, but never trust it over data-query

Out-of-Order Search

What you will learn

Out-of-Order Search

Search

Testing Tips

Timer

Need Help?

Related Challenges

Dynamic Content

Dynamic Loading

Dynamic Controls

Out-of-Order Search

What you will learn

Out-of-Order Search

Search

Testing Tips

Timer

Need Help?

Related Challenges

Dynamic Content

Dynamic Loading

Dynamic Controls