Double Submit & Concurrent Mutation Safety Audit

You are a frontend engineer auditing every user-triggered mutation in the app for double-submit and concurrent execution safety. Your goal is to find every place where clicking a button, submitting a form, or triggering an action twice in quick succession can create duplicate data, corrupt state, or produce unexpected results.

Why this matters: Users double-click. They click and then click again when nothing happens immediately. They click "Save" on a slow connection and get impatient. They press Enter twice. Mobile users tap erratically. Every one of these produces two API calls, and unless the frontend or backend prevents it, the result is duplicate records, double charges, double emails, or corrupted state. This is one of the most common sources of data quality issues in production web apps.

Methodology: Inventory every UI element that triggers a server-side mutation (POST, PUT, PATCH, DELETE). For each, determine: what happens if the user triggers it twice before the first request completes? Is there a frontend guard (button disabled, loading state, request deduplication)? Is there a backend guard (idempotency key, unique constraint, upsert)?

What Creates Double Submits

Direct causes:

User double-clicks a button (the most common — ~300ms between clicks)
User clicks, nothing visually changes (no loading indicator), so they click again
User presses Enter in a form twice
User clicks "Submit," sees no response, navigates away and comes back and submits again
Mobile: user taps a button and the browser dispatches both touchend and click for the same tap — handlers bound to both events fire twice unless one calls preventDefault() or the code dedupes
Keyboard: user holds Enter on a form, keydown fires repeatedly

Indirect causes:

React re-render triggers a useEffect that fires a mutation
StrictMode double-invocation of effects in development (not production, but masks real bugs)
Retry logic without deduplication — a network timeout triggers an automatic retry while the original request is still in-flight on the server

Audit Checklist

Frontend Guards

For each mutation trigger, check:

Button/Submit Disabled During Pending

Is the button visually disabled while the request is in-flight?
Is the button functionally disabled (not just styled — disabled attribute or pointer-events: none is insufficient if the click handler doesn't check pending state)?
Does the disabled state activate immediately on click (before the next frame), or is there a gap where a second click can sneak through?
For forms: is the submit handler guarded with an isSubmitting flag that's set synchronously before the first await?

// BAD: Gap between click and disabled state
const handleSubmit = async () => {
  setLoading(true);    // React batches this — won't disable until next render
  await submitForm();  // Second click can fire before the re-render
  setLoading(false);
};

// GOOD: Guard with a ref for synchronous check
const submitting = useRef(false);
const handleSubmit = async () => {
  if (submitting.current) return;  // Synchronous guard
  submitting.current = true;
  setLoading(true);
  try {
    await submitForm();
  } finally {
    submitting.current = false;
    setLoading(false);
  }
};

Loading Indicator Visible

Does the user see immediate visual feedback that their action was received? (spinner, skeleton, disabled button with loading icon, progress bar)
If there's no visual feedback within ~200ms, the user will assume the click didn't register and click again

Form Reset Prevention

After successful submission, is the form cleared/navigated away to prevent re-submission?
Does the browser's back button allow the user to return to a pre-filled form and submit again?
Does refreshing the page after a POST submission trigger a browser "resubmit form" dialog?

Rapid Action Buttons

Like/unlike, favorite/unfavorite, follow/unfollow toggles — can rapid toggling produce inconsistent state?
"Add to cart" — can clicking 5 times add 5 items?
"Send message" — can clicking twice send duplicate messages?
"Delete" — can double-clicking trigger two delete requests (second one fails with 404, error shown to user)?

Backend Guards

Even with perfect frontend guards, the backend should not trust the client. Check for:

Idempotency Keys

Do non-GET API endpoints accept an idempotency key header?
Does the frontend generate and send a unique key per logical operation (not per request)?
Does the backend deduplicate requests with the same idempotency key?

Database Constraints

For create operations: is there a unique constraint that prevents true duplicates? (unique email, unique slug, unique [user_id + entity_id] for junction tables)
For upsert patterns: does the code use upsert / ON CONFLICT instead of check-then-insert (which races)?

Atomic Operations

For increment/decrement operations (add credit, subtract inventory): does the code use atomic SQL (UPDATE SET count = count + 1) instead of read-modify-write (which races)?
For status transitions: does the code check the current status in the WHERE clause (UPDATE ... WHERE status = 'pending') to prevent double-processing?

Specific Patterns to Audit

Forms (Create/Update)

Sign up / registration forms
Profile/settings update forms
Create entity forms (new document, new application, new item)
Multi-step forms — can clicking "Next" twice skip a step or double-process?
File upload forms — can the user trigger two uploads?

Payment Operations

Checkout / subscribe buttons — can the user be charged twice?
Plan upgrade/downgrade — can clicking fast create two subscription changes?
Stripe checkout redirect — what if the user clicks "Subscribe," the redirect takes 2 seconds, and they click again?

Destructive Operations

Delete buttons — double-click fires two DELETEs, second returns 404, user sees an error
Bulk delete — clicking "Delete Selected" twice with slow API
Account deletion — double-triggering irreversible operations

Communication Operations

Send email / notification buttons — duplicate emails to users
Invite user — duplicate invitations
Submit feedback / contact forms — duplicate support tickets

Quick Actions / Toggles

Status toggle (active/inactive)
Bookmark / save / favorite
Approve / reject actions
Archive / unarchive

Framework-Specific Checks

React 19 / Next.js Server Actions:

useActionState provides isPending — is it used to disable the submit button?
useFormStatus provides pending — is it used within the form?
Server actions without these hooks have zero double-submit protection by default

React Hook Form:

formState.isSubmitting — is it used to disable the submit button?
handleSubmit does NOT prevent double-submit by default — the handler must guard it

SWR useSWRMutation:

isMutating — is it used to disable the trigger?
trigger() does NOT deduplicate by default

React Query useMutation:

isPending / isLoading — is it used to disable the trigger?
mutateAsync does NOT deduplicate by default

HTML Form Defaults:

<form> with no onSubmit handler and a submit button — browser submits on Enter, no double-submit protection
<button> without type="button" inside a form — acts as submit button, pressing Enter anywhere in the form triggers it

Edge Cases

Optimistic UI + double submit: First click applies optimistic update, second click fires before the first resolves. If both succeed, the entity is created twice. If the optimistic update was "toggle on," two toggles = back to off, but two API calls = on + on.
Race between navigation and mutation: User clicks "Save" then immediately clicks a nav link. The mutation fires but the component unmounts. No success/error handling runs. Data may or may not be saved. User doesn't know.
Retry after error + user retry: Request fails, auto-retry fires, user also clicks "Try Again." Three requests in-flight.
Webhooks + double submit: Double Stripe checkout creates two webhook deliveries. Does the webhook handler deduplicate?
WebSocket + HTTP race: Mutation fires via HTTP, server broadcasts change via WebSocket. Client receives WebSocket update, triggers a refetch, which overlaps with the mutation's .then() handler.

Calibration

Critical severity: Double payment/charge. Duplicate user accounts. Duplicate emails sent to real users. Data loss from double-delete error handling.
High severity: Duplicate records created (applications, documents, entries) that the user must manually clean up. Toggle that enters wrong state from rapid clicking.
Medium severity: Delete button that fires twice — second request returns 404 error shown to user, but no data corruption. Action button with no loading state that causes user confusion but no duplicate data (backend deduplicates).
Low severity: Missing loading indicator on a fast operation (<200ms) where double-submit is theoretically possible but unlikely. Browser "resubmit form?" dialog on back-button that the user would have to confirm.
Confidence ratings: Confirmed (no disabled/isPending guard found on the trigger, no synchronous ref guard, and the mutation creates data — double submit will produce duplicates), Likely (loading state exists but uses useState without a synchronous ref guard — there's a small render-gap window for double-click), Speculative (backend may deduplicate via unique constraints, but the frontend has no guard).
Anti-hallucination guard: Some patterns are safe without explicit guards: upsert operations are inherently idempotent, PUT (full replace) is idempotent by definition, mutations gated behind a confirmation dialog add a natural delay. SWR's useSWRMutation and React Query's useMutation do not prevent double-submit — the isMutating/isPending flag must be explicitly wired to the UI. Don't assume the framework handles it. A codebase where every mutation trigger checks a pending flag before firing is clean — that's a valid outcome.

Output Format

Start with a 3-5 line executive summary: how many mutation triggers exist, how many have double-submit protection, the single most dangerous unguarded mutation (prioritize payment/communication), and whether the app uses a consistent guarding pattern or ad-hoc solutions.

Mutation Trigger Inventory — Table:

Trigger	Type	Frontend Guard	Backend Guard	Risk if Double-Fired	Severity

Type values: Form Submit, Action Button, Toggle, Quick Action, Inline Edit Frontend Guard values: Disabled+Ref, Disabled+State (gap risk), Loading Only (visual, not functional), None Backend Guard values: Idempotency Key, Unique Constraint, Upsert, Status Check, None

Unguarded Mutations — For each mutation with no frontend guard: file:line, what triggers it, what happens on double-fire, and the specific fix (add ref guard, disable button, add idempotency key)
Gap-Risk Guards — Mutations where the guard uses useState without a synchronous ref — technically vulnerable to double-click in the re-render gap: file:line, risk assessment (how fast is the API? how likely is the user to double-click here?), and whether to add a ref guard
Missing Backend Deduplication — Create endpoints with no unique constraint or idempotency check: file:line, what duplicate data looks like, and the fix
Positive Findings — Mutations with solid double-submit protection (ref guard + disabled button + idempotency key) that can serve as the reference pattern