RTK Query mutation retry logic versus manual idempotency-keyed writes

In Redux Toolkit Query, queries support automatic retries via the baseQuery configuration, but mutations are intentionally not retried by default to prevent unintended side effects. When dealing with unstable network conditions, developers must choose between implementing a manual retry loop within the component layer or utilizing server-side idempotency keys.

Relying on manual retries allows for granular control over the backoff strategy but increases the complexity of the state logic. Conversely, implementing idempotency keys requires storing client-generated IDs in the Redux state to ensure that the backend can ignore duplicate requests resulting from a retried mutation.

Which approach provides better consistency for preventing duplicate records when a mutation times out before receiving a response? How should the lifecycle of an idempotency key be managed within the Redux store to prevent memory leaks after successful execution?