Implement a submit handler that cannot send two requests from rapid clicks or Enter presses.

• Guard synchronously.
• Disable the submit button.
• Reset the guard in finally.
• Use a server-supported idempotency key for consequential writes.

A ref closes the gap before the pending render, while state communicates progress. I also keep one attempt object containing the normalized command and idempotency key. A definitive rejection clears that attempt so corrected input can start a new operation; an ambiguous transport failure retains it, so Retry sends the same payload with the same key instead of risking a duplicate order.

type Attempt = {
  key: string;
  command: CreateOrderInput;
};

const submittingRef = useRef(false);
const attemptRef = useRef<Attempt | null>(null);
const [pending, setPending] = useState(false);
const [error, setError] = useState<string | null>(null);

async function submit(event: FormEvent) {
  event.preventDefault();
  if (submittingRef.current) return;

  submittingRef.current = true;
  setPending(true);
  setError(null);

  const attempt = attemptRef.current ?? {
    key: crypto.randomUUID(),
    command: normalizeOrder(values),
  };
  attemptRef.current = attempt;

  try {
    await api.createOrder(attempt.command, {
      idempotencyKey: attempt.key,
    });
    attemptRef.current = null;
  } catch (caught) {
    if (isDefinitiveRejection(caught)) {
      attemptRef.current = null;
      setError("Review the order details and try again.");
    } else {
      setError("The result is uncertain. Retry to check the same order.");
    }
  } finally {
    submittingRef.current = false;
    setPending(false);
  }
}

return <>
  <button type="submit" disabled={pending} aria-busy={pending}>
    {pending ? "Creating order" : "Create order"}
  </button>
  {error ? <p role="alert">{error}</p> : null}
</>;

isDefinitiveRejection should be based on the API client's typed outcome, not on guessing from a generic exception. While an outcome is uncertain, Retry reuses the captured command and key; changing it should be an explicit new operation after reconciliation.

The client guard improves UX; database-backed idempotency provides correctness if the browser retries after an uncertain response.

• The request fails immediately.
• The component unmounts.
• A browser/network retry occurs.
• The user retries intentionally.

• Dispatch two submits in one act block and assert one request.
• Reject definitively, correct the input, and assert the retry gets a new key.
• Simulate an ambiguous transport failure and assert Retry uses the same payload and key.
• Resolve the retry successfully and assert the next logical order gets a new key.

• Relying only on disabled rendering.
• Never clearing pending after error.
• Generating a new key during transport retry.
• Claiming UI state guarantees server uniqueness.