Duplicate writes on retried Remix actions and POST-Redirect-GET limits

A design goal is to ensure mutations handled by a Remix route action are applied once even when a client retries a request before receiving a response.

Remix processes mutations in route action functions for POST, PUT, PATCH and DELETE requests and the conventional success response is a redirect to a GET route. The framework does not provide built-in idempotency keys or automatic request deduplication for retried network requests. POST-Redirect-GET is the primary framework-level safeguard against browser refresh resubmission, not against transient network retries that occur before the redirect is received. Client helpers such as useFetcher and the Remix Form component can re-submit an action on navigation or retry, so the location and mechanism for enforcing uniqueness is left to application code.

With version assumptions for the Remix web framework with server-side actions and practical verification still required, the unresolved decision is which documented pattern is appropriate for safe form actions under retry conditions.

Does Remix document any client-side deduplication behavior for useFetcher or Form submissions? Which documented server-side pattern is recommended for safe form actions when retries are possible? When should uniqueness be enforced in the action versus in the data layer?