After a network failure the button must unlock into a clear error

What it is

A lock blocks a second hit while a request is in flight. On failure—timeout, 4xx, offline—the lock must release, and the button or its neighborhood must enter a clear error, not silently return to rest, and not spin forever. Still locked after failure, people kill the app. Unlocked with no explanation, they will click again, which is fine, but without an error both failures are invisible.

Why it happens

Failure ends the in-flight phase, so the button must become sendable. If failure is treated as “still loading,” the spinner never dies and the model is “the system is dead.” If failure only unlocks, with no copy change and no notice, the UI is indistinguishable from rest: people do not know whether to edit the form or retry, and they mash the same error. The error state answers three things: it did not succeed, why (what can be said), you may try again. Unlock is behavior; error is look and copy; doing one is a stump. Timeouts are nasty: the client has failed, the server may still succeed, and unlocking then sending can double-write. The failure path still needs an idempotency token; that is not a reason to stay locked.

Studying it

Make the submit API time out, return 400, or go offline. Compare: spinner after failure, rest with no message, unlock plus error.

Independent variables: failure kind, whether it unlocks, whether the error sits by the button. Dependent variables: retries, app-kills, ability to name the cause, duplicate success after a late write.

Telling people “this is a failure test” makes them wait. Use a flow that looks like a real payment to see app-kills.

Where it stops holding

Auth failure should sometimes stay locked and divert to sign-in, not unlock so they pay again. Idempotent retry may keep loading automatically, with a cap and a final error. Offline queueing is not failure: say “will send when online,” not error red. Partial success (some items in a batch) should, after unlock, point at the failed items, not one “error” on the whole button.

Applying it

• Unlock in the catch / timeout branch, pull the button from loading into an error look, and say retry is possible.
• Do not use color alone; put words in or beside the button.
• Keep a request token so a retry after timeout does not collide with a late success.
• Verify by submitting offline. The spinner must stop, the button must be hittable, the cause must be readable. A stuck spinner or a silent return to rest means the failure path is unfinished.

Related

• Within the group: E1.17.1 Click-submit and Enter-submit must share one lock · E1.17.2 Touch delay can let two quick taps both count as valid · E1.17.4 Optimistic UI can desynchronize unlock from result feedback
• Adjacent: E1.09 Loading buttons · H3.02 Three parts of an error message · E6.03 Inline validation
• Search terms: submit error · unlock on failure · timeout