Prevent duplicate inquiries from repeated form submissions

What counts as the same submission?

Define one logical submission before adding a loading spinner. A double click with unchanged fields is usually one intended action. Retrying after a lost response can also be the same action. A deliberate later inquiry with different content may be new work. The interface and server need a shared way to tell these cases apart.

W3C WAI recommends communicating errors, correction instructions and success feedback. Those messages need to reflect the actual submission state. A spinner can show pending work, but a success message should not appear until the application has the required evidence of acceptance. [User notification]

A UI and server behavior table

Button disabling is useful feedback, but two tabs, a replayed request or an impatient retry can bypass it. Enforce deduplication where the record is committed. Use a unique request identity and an atomic storage rule rather than a preliminary lookup that can race with another request.

Keep the ID through a retry

Create an ID when the logical operation begins and retain it until the outcome is resolved. Send the same ID and normalized payload on a retry. If the server already saved the operation, return the matching receipt. If the same ID arrives with different content, report a conflict instead of silently overwriting or duplicating the inquiry.

Fixture: duplicate-after-timeout
1. Submit request fixture-001.
2. Commit one inquiry, then drop the response.
3. Retry fixture-001 with the same payload.
4. Expect the same receipt and exactly one inquiry.
5. Confirm one queued notification identity.

Avoid saving sensitive form contents in unrestricted browser storage merely to make retries convenient. Choose a recovery mechanism appropriate to the data and session. The acceptance requirement is stable operation identity and honest recovery, not persistence of every field indefinitely on a shared device.

What should the user see?

Use “Sending your inquiry” while the outcome is pending. If a receipt confirms the durable save, say that the inquiry was received. If the network response is missing, say that confirmation could not be obtained and offer a retry that preserves the operation identity. Do not tell users to submit again under a fresh ID by default.

Keep focus and field values predictable when an error occurs. WAI’s form guidance supports associated labels and helpful recovery notifications. A disabled control should not trap keyboard users or erase the context they need to continue. Test this behavior in the actual browser, not only by inspecting button attributes. [Labeling controls] [User notification]

• Verify one record after simultaneous requests.
• Verify a matching receipt after a lost-response retry.
• Verify edited content does not silently reuse the previous operation.
• Verify pending and unavailable states preserve a usable path forward.
• Verify public analytics contain no contact text or request identifier.

Inspect the stored effect

A passed interface test is only half the evidence. Check durable record counts, operation identities and notification state after the fixture. A second HTTP success may correctly return an existing receipt, so counting responses cannot tell you how many inquiries were created. Record the observed effect and keep delivery verification separate from business qualification.

• Read the broader guide for this workflow
• Put the method into practice
• Design idempotent automation retries
• Write truthful confirmation states

Sources

AI-assisted writing and an AI-generated editorial cover. Source links and checked dates are listed below; illustrative examples are labeled in the text.

• User notification — checked 2026-10-18
• Labeling controls — checked 2026-10-18