Why are stale search requests problematic and how do you cancel them?

WHAT THIS TESTS: This question probes whether you understand the race condition created by overlapping asynchronous network calls in a user interface. Specifically, it checks if you recognize that network latency is not deterministic, so request two may return before request one, and that unconstrained requests waste client and server resources.

A GOOD ANSWER COVERS: First, the candidate should articulate why the original request is harmful: it consumes unnecessary bandwidth, drains battery via radio usage, and can cause a stale result to clobber the newer correct result if it returns later. Second, the candidate should outline a cancellation strategy, such as using a CancelToken in Dio. The pattern is to store one CancelToken for the current search operation; when a new keystroke arrives, call cancel() on the existing token to abort the in-flight request, then instantiate a fresh token for the new request. Third, a senior candidate should mention that cancellation should be paired with debouncing so that rapid keystrokes do not spawn requests at all, but debouncing alone is insufficient because even a 300 millisecond debounce window can still produce overlapping requests on slow networks.

COMMON WRONG ANSWERS: A weak answer suggests debouncing is enough and ignores cancellation entirely. Another red flag is claiming that setting a new state variable will simply ignore the old response; this prevents the UI from updating but still wastes the network and battery cost. Some candidates also propose global mutexes or sequential queues that block the new request until the old one finishes, which artificially slows the user experience instead of prioritizing the latest input.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle this if the API does not support cancellation, in which case you might track request sequence numbers and drop responses that arrive out of order. They might also ask how cancellation interacts with error handling, specifically catching the DioException with type DioExceptionType.cancel to avoid logging an aborted request as a failure. Another follow-up is how this scales to a repository pattern or BLoC architecture, where the cancellation logic should live in the data layer rather than the widget.

ONE CONCRETE EXAMPLE: Imagine a search field on a product catalog. The user types flutte, triggering a search at the 300 millisecond debounce mark. The request is dispatched with CancelToken A. While the request is in flight, the user types r, making the term flutter. Before dispatching the new request with CancelToken B, the view model calls cancel() on Token A. Dio tears down the underlying HTTP connection. The new request returns in 80 milliseconds and the UI shows results for flutter. If Token A had not been cancelled, it might have returned two seconds later and overwritten the correct results.

Source: dio package documentation (pub.dev)