Duplicate POST requests on retry cause unintended data creation

Implementing Idempotent Retries in Angular

To prevent duplicate record creation during retries, the retryWhen (or retry in RxJS 7+) operator must be placed before any multicasting operators like shareReplay. If shareReplay is placed before the retry logic, the observable will cache the failed response, and subsequent subscriptions will receive the cached error rather than triggering a new HTTP request.

Recommended Operator Sequence

The stream should follow this order to ensure the request is re-executed and the UI state remains consistent:

1. Request Initiation: The HTTP call is triggered.
2. Idempotency Injection: An interceptor or map operator adds the unique key.
3. Retry Logic: retryWhen handles transient errors and re-subscribes to the source.
4. Multicasting: shareReplay(1) ensures multiple components (like the MatTable and a loading spinner) share the same execution result.

Automatic Idempotency Key Generation

To avoid exposing keys to the UI or manually adding them to every component, implement an HttpInterceptor. This allows the key to be generated and attached to the headers of every POST, PUT, or PATCH request automatically.

// Conceptual Interceptor Logic
intercept(req: HttpRequest<any>, next: HttpHandler) {
  if (['POST', 'PUT', 'PATCH'].includes(req.method)) {
    const idempotentReq = req.clone({
      setHeaders: { 'X-Idempotency-Key': this.generateUuid() }
    });
    return next.handle(idempotentReq);
  }
  return next.handle(req);
}

MatSnackBar Retries and Payload Integrity

A MatSnackBar action does not inherently guarantee an identical payload. If the retry is triggered by calling a function that re-reads values from a form or a state store, the payload may have changed. To guarantee the exact same request is retried, you must capture the original request object (including the idempotency key) in a closure or a service-level state variable and re-emit that specific object into the stream.

Verification Steps

• Network Audit: Open Chrome DevTools Network tab. Trigger a retry and verify that the X-Idempotency-Key remains identical across all attempts for a single operation.
• Server Validation: Verify that the server returns a 200 OK or 201 Created for the first request and a 200 OK (returning the existing resource) or 409 Conflict for subsequent requests with the same key.

Diagnostic Requirement: Please specify if your backend is using a database with unique constraints on natural keys or a dedicated idempotency table, as this determines whether the client should expect a 200 or a 409 response on successful deduplication.