After timeout, state must be explicit, not left waiting
Aliases: timeout state · hung waiting · don't stay on spinner
What it is
The clock fires, the client gives up the request, and the spinner keeps spinning — the worst timeout: the system is no longer waiting, the UI is still pretending to. Post-timeout state must be explicit: leave “in progress”, enter “this attempt did not finish”, and say the next step (retry, check the network, see whether it already submitted). Staying on wait is performing an already finished failure as unfinished hope.
Explicit is not an extra line of small type. It is a real gear-change in the state machine: loading indicators stop, the primary button leaves its working state, and an error or uncertain outcome occupies the place that was waiting for a result.
Why it happens
Wait state occupies the expectation that a result might still arrive. Timeout cuts that possibility. If the visuals still occupy the expectation, people monitor a channel that will not ring again. Monitoring costs attention and blocks the only useful post-timeout act: take another path. Worse is the late response: the UI is still waiting, a tardy result writes itself in, people think the current attempt succeeded when the success belongs to the abandoned one, tangled with the next operation.
So timeout must do two things at once: change gear for the user, and cancel or isolate this request’s callbacks for the program. Gear-change without isolation lets a late write shove explicit state back into chaos.
Where it stops holding
When the product clock times out but the server is still running a long job, the explicit state is “the client has stopped waiting”, plus a query entry — not an assertion that the job failed. On weak networks timeouts may be false; explicit state must be reversible, with retry a first-class action. Automatic retries in flight must not show timeout state — a flash of failure then recovery is a false alarm. Timeout state appears only after the retry budget is spent.
Applying it
- On the same beat as timeout: stop every in-progress indicator, replace with an explicit failed or uncertain outcome, and restore the original action as tappable.
- Copy must distinguish “not connected”, “connected but not finished in time”, and “may have submitted, query first”. Do not file them all under “load failed”.
- Drop or isolate that request’s callbacks. A late 200 must not mutate the current screen.
- How to check: hang the API past the product timeout. The spinner must vanish; a non-waiting state must occupy the screen. Then let the API return success after timeout; that success must not write into the current attempt.