---
title: "Prevent duplicate records on repeated submit"
description: "Verify a pending form submission cannot create duplicate records when the user activates Save again before the first response finishes."
canonical_url: "https://vostride.com/agent-library/forms-validation/double-submit-single-record.md"
md_url: "https://vostride.com/agent-library/forms-validation/double-submit-single-record.md"
content_kind: "recipe"
topic: "forms-validation"
---

# Prevent duplicate records on repeated submit

Verify a pending form submission cannot create duplicate records when the user activates Save again before the first response finishes.

## Risk

Client button disabling and server idempotency protect different failure paths. This UI journey verifies the visible pending state and the resulting record count without claiming to prove every backend replay condition.

## Fixtures

- A staging intake form creates test tickets without sending external messages.
- A prepared fixture delays the first create response while preserving its eventual success, and records committed ticket identifiers.
- The run uses a unique title QA duplicate guard so independent counting cannot include older fixtures.

## Steps

1. Fill the intake form with the unique title and required details, then verify the draft values before submission.
2. Activate Save and verify the interface displays a pending state before the delayed response is released.
3. Attempt the ordinary visible submit control again only if it remains enabled, recording whether it accepts a second activation.
4. Release the prepared response and verify one ticket detail opens with the expected title and body.
5. Reload the ticket list and verify exactly one matching ticket, then compare the count with the independent commit log.

## Expected results

- The final persisted result contains exactly one ticket carrying the run-specific title.
- The pending interface communicates progress and eventually resolves to a usable detail page.
- The external fixture log and UI inventory agree on one created identifier, including any repeated UI activation.

## False-pass traps

- A disabled button alone does not prove no duplicate request was already dispatched.
- Deleting duplicate rows before counting would erase the evidence this journey needs.

## Cleanup

- Remove the response-delay fixture and delete all tickets with the run-specific marker after recording their count.

## Use with agent-qa

Adapt this test design to your application's acceptance criteria and configured target using the [recipe execution guide](/agent-library/software-factory/turn-a-recipe-into-an-agent-qa-test.md). External fixture setup and non-UI checks require your own supported hooks or test tooling. Validate the authored test, execute it, and inspect the completed evidence; this recipe is not a recorded test result.

## References

- [agent-qa test](/docs/agent-qa/configuration/test.md)
- [agent-qa first test](/docs/agent-qa/guides/first-test.md)
- [agent-qa web testing](/docs/agent-qa/guides/web-testing.md)

- [Forms and validation QA recipes](/agent-library/forms-validation.md)
- [Software factory QA library](/agent-library.md)