Duplicate POST requests on retry cause unintended data creation

The goal is to configure retry logic for create/update operations (POST/PUT/PATCH) that feed an Angular Material MatTable so that transient server errors are retried without causing duplicate records. The solution must keep the mat‑progress‑spinner visible during retries, avoid altering the original user‑initiated payload, and work with the existing CDK Directionality and Portal services.

Uncertainty remains about where to place the retryWhen operator relative to shareReplay or similar multicasting operators so that a failed attempt does not get cached and subsequent retries actually re‑send the HTTP call. Additionally, it is unclear how to generate and attach an idempotency key automatically within the data‑source stream without exposing the key to the UI or requiring manual handling in each component. Finally, developers wonder whether using a MatSnackBar action to trigger a retry can guarantee that the exact same request body is retried, or whether extra safeguards are needed to prevent duplicate writes. What is the recommended placement of retryWhen relative to shareReplay to ensure retries re‑execute the call? How can an idempotency key be added automatically to the request stream without UI exposure? Does a MatSnackBar‑triggered retry guarantee identical payloads, or must additional client‑side deduplication be applied?