Form submissions need an uncertain state when the server response is lost

A browser form can send an enquiry that the server saves while the response never reaches the page, leaving the interface unsure whether it succeeded. The article argues that displaying a generic failure message asserts something the browser cannot know, and that disabling buttons does not prevent duplicate server-side work. It describes a four-state controller (ready, sending, received, uncertain) that only treats a response as received when the HTTP status is successful, the JSON body confirms success, and a UUID-shaped reference is present. Ambiguous outcomes such as lost connections or malformed responses enter the uncertain state, where the page avoids automatic resending and offers an alternative contact route. The author notes that this approach is conservative, is not an exactly-once guarantee, and that endpoints supporting idempotency keys should follow their own documented contracts.