Preventing Duplicate Writes on Remix Action Retries

The Solution: Client-Generated Idempotency Keys

To guarantee that a single user intent results in only one database write, you must implement a Client-Generated Idempotency Key pattern. Since Remix does not provide built-in request deduplication, you must generate a unique identifier on the client, send it with the Action request, and validate it on the server before executing the mutation.

Implementation Steps

1. Client-Side Generation: Generate a UUID (e.g., using crypto.randomUUID()) when the form is first rendered or when the user initiates the action. Store this key in a hidden input field within the <Form> or pass it via useSubmit.
2. Server-Side Interception: In the action function, extract the key from the formData: const idempotencyKey = formData.get("idempotencyKey");.
3. Atomic Check-and-Set: Before performing the write, check a fast, short-lived store (like Redis or a dedicated database table) to see if the key has already been processed.
4. Execution and Storage: If the key is new, execute the database write and store the key in the cache with a Time-To-Live (TTL) of 5–30 minutes. If the key exists, skip the write and return the previous result or a success response.

Strategy Comparison

Storage Method	Pros	Cons
Redis (SET NX)	Atomic, high performance, shared across server instances.	Requires additional infrastructure.
Session Cookie	No extra infra; tied to the user session.	Limited to ~4KB; can be cleared by the user.
DB Unique Constraint	Absolute data integrity.	Causes hard errors that must be caught/handled; doesn't prevent the Action logic from running.

Verification and Safety

To verify this implementation, use a test Action that increments a counter. Submit the form and manually trigger a second request with the same key; the counter should only increment once. For production safety, ensure the key is namespaced by the User ID to prevent collisions across different accounts.

Diagnostic Question: Are you operating in a multi-server/distributed environment? If so, a session-cookie approach will fail unless you use a shared session store, making Redis the recommended path.