Choose against the task constraints
A fictional staff search applies status=ready. One completed response returns zero matching records. Another request fails with no usable response, and a third is still pending. Only the first establishes that the current search found nothing.
| Condition | Successful empty state | Unavailable/pending state |
|---|---|---|
| Completed zero-result response | Explain which filter found no records | An outage message would be inaccurate |
| No trustworthy response | Cannot claim the queue is empty | Offer retry or preserve prior labelled data |
| Request still pending | Do not announce final zero matches | Display current loading state without replacing certainty |
Keep response status separate from result length. A failed fetch must not fall through to an empty array that looks like a successful search. If retaining an earlier result, name its earlier status rather than presenting it as newly verified.
Classify the three outcomes
| Request | Observed evidence | Display |
|---|---|---|
| R-A | Completed; matches=[] | No ready records |
| R-B | Failed; no body | Search unavailable |
| R-C | Promise pending | Loading |
Can R-B show the same empty message as R-A?
Show the worked answer
No. R-B provides no evidence about the number of ready records. Keep the unavailable state and allow recovery without inventing an empty queue.
Check the chosen interaction
- Test successful zero, failure and pending as separate cases.
- A late response from an older query cannot overwrite a newer search.
- Retry preserves the intended filter and entered query.