Which strategy prevents duplicate writes during mutation retries in SolidJS?

The short answer

Use a client-generated idempotency key that is created once per logical mutation (not per attempt), sent with every retry — typically as an Idempotency-Key header — and deduplicated on the server. SolidJS's createResource, mutate, and refetch only synchronize reactive UI state; they provide no network delivery guarantees, so deduplication must live in your fetch wrapper and your backend.

Confirmed facts vs. likely explanation

Confirmed: SolidJS resources manage the UI lifecycle of async data (loading, resolved, error) and let you push local values with mutate or re-sync with refetch. Nothing in that layer prevents two identical HTTP requests from reaching the server.

Likely explanation (standard API practice, not SolidJS-specific): the established pattern — used by payment APIs such as Stripe — is that the client attaches a unique key to the operation, and the server stores the key alongside its result. If the same key arrives again, the server returns the stored response instead of executing the write a second time. This requires server cooperation; client code alone cannot guarantee deduplication.

Integrating the key into the SolidJS mutation flow

1. Generate the key outside the retry loop, when the user initiates the operation (e.g., crypto.randomUUID()).
2. Pass it into your fetcher so every attempt of that operation sends the identical header.
3. Rotate the key only when the user intentionally starts a new operation.

async function submitOrder(payload) {
  const key = crypto.randomUUID(); // once per logical operation

  const attempt = () => fetch('/api/orders', {
    method: 'POST',
    headers: { 'Idempotency-Key': key, 'Content-Type': 'application/json' },
    body: JSON.stringify(payload),
  });

  let res;
  for (let i = 0; i < 3; i++) {
    try { res = await attempt(); break; }
    catch (e) { if (i === 2) throw e; await delay(2 ** i * 300); }
  }
  return res.json();
}

The critical rule: never generate the key inside the retry function — each attempt would look like a distinct operation and deduplication would silently fail.

Reconciling local state after an ambiguous timeout

When a retry fires after a timeout, do not assume the previous attempt failed — the server may have processed it. The safe sequence is:

1. Retry with the same idempotency key. A deduplicating server returns the original result rather than writing again.
2. On resolution, call refetch() (or apply the returned canonical entity via mutate) so local state converges to server truth.
3. For optimistic updates, keep the optimistic value separate and overwrite it with the authoritative response; roll back only after a definitive, non-retryable failure (e.g., a 4xx validation error).

Verification

• Stub fetch to fail once then succeed; assert the same Idempotency-Key header appears on both attempts.
• On the server, send the same key twice and confirm only one record is created and both responses match.
• Simulate a timeout after server processing, then refetch and confirm local state converges to a single record.

Note: SolidJS APIs evolve — verify createResource/mutate semantics against your installed version's docs. The idempotency pattern itself is version-independent but only works if your backend implements key-based deduplication (a unique constraint or key store with an expiry window).