RTK Query mutation retry logic versus manual idempotency-keyed writes

Direct Answer

Server-side idempotency-keyed writes provide stronger consistency for preventing duplicate records when a mutation times out. Manual retry loops in the component or thunk layer cannot guarantee exactly-once semantics without server cooperation, and they increase state logic complexity.

Why Idempotency Keys Win on Consistency

RTK Query intentionally does not retry mutations by default (confirmed behavior across current versions). When a network timeout occurs, the client cannot know whether the server processed the request. A manual retry loop simply resends the same payload, which the server will treat as a new request unless it can recognize a duplicate.

An idempotency key — a client-generated unique identifier sent with the mutation — lets the server deduplicate retried requests. The server stores the key with the result of the first successful execution and returns the cached response for subsequent requests bearing the same key. This shifts the consistency guarantee to the backend, where it belongs.

Managing Idempotency Key Lifecycle in Redux

To avoid memory leaks, tie key storage to the mutation lifecycle, not component mount:

1. Generate once per logical operation — create a stable key (e.g., UUID) before dispatching the mutation, and include it in the request body or header.
2. Track pending keys in a slice — store the key with a minimal payload (timestamp, operation type) in a dedicated Redux slice or RTK Query's meta while the mutation is in flight.
3. Remove on terminal state — delete the key in the onQueryStarted finally block or via a fulfilled/rejected listener when the mutation reaches a definitive outcome (success, explicit failure, or cancellation).
4. Bound the retention — add a background cleanup (e.g., a middleware or setInterval) that prunes keys older than a configurable TTL (e.g., 5–10 minutes) to handle edge cases like tab close or crashed listeners.

Minimal Implementation Sketch

// idempotencySlice.ts
const slice = createSlice({
  name: 'idempotency',
  initialState: {} as Record,
  reducers: {
    register(state, action) { state[action.payload.key] = { ts: Date.now(), op: action.payload.op }; },
    release(state, action) { delete state[action.payload.key]; },
  },
});

// In mutation definition
mutation: build.mutation({
  queryFn: async (args, { dispatch, extra, requestId, signal, getState }) => {
    const key = crypto.randomUUID();
    dispatch(slice.actions.register({ key, op: 'createOrder' }));
    try {
      const res = await fetch('/api/orders', {
        method: 'POST',
        headers: { 'Idempotency-Key': key, 'Content-Type': 'application/json' },
        body: JSON.stringify(args),
        signal,
      });
      return { data: await res.json() };
    } finally {
      dispatch(slice.actions.release({ key }));
    }
  },
});

One Diagnostic Detail Needed

Does your backend already accept and honor an Idempotency-Key header (or equivalent) and return the original response for duplicates? If not, the client-side key management alone cannot prevent duplicates — the server must participate.