AbortError on fetch abort: retrying POST without duplicate writes

Answer the question first

When a Fetch request is aborted with AbortController, retrying the same POST or PUT can create duplicate resources because the HTTP spec offers no built‑in retry‑intent signal. The client can add an arbitrary header (e.g., Idempotency-Key or Retry-Intent: idempotent), but the server must understand that header and act accordingly.

Client‑side indication

• Generate a unique key per logical operation (UUID, hash of payload + user ID).
• Send the key in a custom header:

  fetch(url, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Idempotency-Key': '123e4567-e89b-12d3-a456-426614174000'
    },
    body: JSON.stringify(data),
    signal: controller.signal
  });
  

• On retry, resend the exact same method, URL, body, and headers.

Spec support

The Fetch API allows any custom header; it does not define a dedicated retry‑intent header. Intermediate proxies normally forward unknown headers, but corporate firewalls may strip them, so test the full network path.

Server‑side patterns

1. Idempotency‑key table: Store the key with the operation’s result. On a repeat request with the same key, return the stored response instead of executing the write again.
2. Natural uniqueness: Enforce database constraints on a deterministic field derived from the request (e.g., hash of body + user ID). If a duplicate is detected, return 409 Conflict or the existing resource.
3. Expiration policy: Keep idempotency entries for a configurable window (e.g., 24 h) to prevent unbounded storage growth.
4. Atomicity: Persist the idempotency key transactionally with the write to avoid a race where the first request partially succeeds.

Practical steps to coordinate retry logic

1. Generate a UUID once per logical operation and include it in the Idempotency-Key header.
2. Abort the request when needed using AbortController.
3. Retry the exact same request (method, URL, body, headers) after the abort.
4. Verify that the server returns the same status and body as the first attempt and that no new resource is created (inspect the database or resource list).
5. If the server supports idempotency keys, you should see a 200 OK with the original response instead of a new record.
6. If the server does not support idempotency keys, you should see a 409 Conflict or the existing resource representation.

Diagnostic question

Does your backend already expose an Idempotency-Key endpoint or similar mechanism? Knowing this will determine whether you need to implement a custom duplicate‑detection strategy on the server side.