Preventing duplicate mutations when using Apollo Link Retry

Question

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?

Tasadduq Burney · Answer

Handling Mutation Retries in Apollo Client
Apollo Client does not provide a built-in mechanism to synchronize or deduplicate mutations across RetryLink attempts. Because RetryLink operates at the network layer, it simply resends the request payload. It has no internal logic to determine if a previous attempt was partially processed by the server.

Cache Behavior and Optimistic Updates
When using optimistic responses, the local cache is updated only once—at the moment the mutation is first triggered. Subsequent retries managed by RetryLink do not re-trigger the optimistic update process. The cache remains in the optimistic state throughout the entire retry cycle until one of two things happens:

Success: The server returns a successful response, and the optimistic data is replaced by the actual server data.
Failure: The retry policy is exhausted, and the error handler is triggered, causing Apollo Client to automatically roll back the optimistic update.

Recommended Strategy for Idempotency
To prevent duplicate server-side writes during network timeouts, you must implement idempotency at the application level. The recommended approach is as follows:

Generate a Client-Side Key: Create a unique UUID (Idempotency Key) for the specific operation before calling the mutation.
Pass Key as Argument: Include this key as an argument in your GraphQL mutation.
Server-Side Deduplication: The server should check if a request with that specific key has already been processed. If it has, the server should return the original successful response without executing the logic again.

Verification Steps
To ensure your implementation is resilient, perform these checks:

Network Inspection: Use browser developer tools to simulate a "Request Timeout." Confirm that RetryLink sends multiple requests with the same payload.
Cache Validation: Use Apollo Client DevTools to verify that the optimistic update is applied once and does not create duplicate entries in the cache during retries.
Server Logic Test: Manually send two identical mutation requests with the same idempotency key and verify that only one record is created in the database.

Note: To provide a more specific recommendation on cache reconciliation, please clarify if you are using a custom update function or relying solely on optimisticResponse.

Preventing duplicate mutations when using Apollo Link Retry

Idempotency in Apollo Client Retries

1 answer

Handling Mutation Retries in Apollo Client

Cache Behavior and Optimistic Updates

Recommended Strategy for Idempotency

Verification Steps

Your perspective belongs here.

0 question comments