Can a purely static Jamstack client safely retry a serverless write without duplicating the mutation?

Question

In a Jamstack build, write operations are typically delegated to serverless functions or third-party APIs rather than the static host itself. When a browser times out waiting for a response, the endpoint may have already committed the write, so a naive retry can duplicate the effect unless the receiving service enforces idempotency.

Idempotency keys are a documented pattern for this problem: the client sends a unique identifier with each mutation, and the server stores the key to recognize and deduplicate retries within a retention window. However, purely static sites lack a default server-side session to correlate retries across devices. Browser storage such as localStorage or sessionStorage is per-device and can be cleared, leaving an unresolved decision about where to generate and persist the key so that retries remain safe across reloads and different browsers.

Some Jamstack form and API providers expose explicit idempotency or deduplication controls, while others rely on natural keys or client-side guards, making the retry contract inconsistent across services. Given that key retention periods and storage limits are provider-specific and may change, which client-side persistence strategy offers the most reliable deduplication for static sites, and how should developers verify that a chosen provider actually honors the key across a timeout-induced retry?

Tasadduq Burney · Answer

Answer
Yes – a purely static Jamstack client can safely retry a serverless write without causing duplicate mutations, provided the backend honors an idempotency key and the client persists the same key across retries using client-side storage.
How it works
The client generates a unique identifier (UUIDv4) for each logical write attempt, stores that identifier in a durable client-side store (IndexedDB) before sending the request, and includes it as an Idempotency-Key header. If the request times out, the client retries with the same key; the server recognises the key and returns the original result instead of performing a second write.
Steps to implement

Generate a UUIDv4 (e.g., using crypto.randomUUID()).
Persist the UUID in IndexedDB under a store keyed by the operation's natural identifier (e.g., form ID or user‑intent).
Send the serverless request with the header Idempotency-Key: <uuid>.
On a successful response (2xx), delete the stored key.
On a timeout or network error, read the stored key and retry the request with the same header.
If the server returns an error indicating the key is unknown, treat it as a new attempt and generate a fresh UUID.

Verification

Instrument the client to log the UUID and simulate a network timeout after the request is sent (e.g., using fetch with AbortController after a short delay).
Retry the request with the same UUID and verify the server returns the original response without creating a second record (check via a subsequent read or provider dashboard).
Send a second request with a different UUID and ensure a new record is created, proving the server uses the key for deduplication.

Missing diagnostic detail: Does the provider document explicit support for the Idempotency-Key header and specify its retention window? Knowing this changes whether the client‑side strategy can be trusted.

Can a purely static Jamstack client safely retry a serverless write without duplicating the mutation?

1 answer

Answer

How it works

Steps to implement

Verification

Your perspective belongs here.

0 question comments