Preventing duplicate mutations when using Apollo Link Retry

Idempotency in Apollo Client Retries

Apollo Client utilizes RetryLink to automatically resend failed requests based on a defined retry policy. While this ensures resilience against transient network failures, it introduces a risk for GraphQL mutations. If a request reaches the server and is processed, but the response is lost due to a timeout, the subsequent retry may result in duplicate writes.

Standard HTTP retry mechanisms do not natively guarantee idempotency for mutations. To prevent duplicate data entries, developers typically implement client-generated idempotency keys passed as mutation arguments, requiring the server to track and deduplicate these requests.

There is uncertainty regarding the interaction between these retries and optimistic UI updates. Specifically, it is unclear how the local cache should reconcile multiple retry attempts to avoid inconsistent states before the server finally confirms the operation.

• Does Apollo Client provide a built-in mechanism to synchronize optimistic updates across multiple RetryLink attempts?
• Which strategy is recommended for managing the local cache state when a mutation is retried multiple times before succeeding?