shareReplay with takeUntil: need explicit buffer reset on destruction signal

Answer

If you can guarantee that no component or service keeps a subscription to the shareReplay after the destruction signal, you do not need a manual reset; the refCount will drop to zero when takeUntil completes the source and the internal Subject will be unsubscribed, clearing the buffer.

If any lingering subscription might remain (e.g., a long‑lived service that never unsubscribes), you should expose a reset method to forcibly clear the replay buffer.

Confirmed facts

• shareReplay creates a ConnectableObservable with an internal Subject that stores the last N values.
• The buffer is retained as long as the shared subscription’s refCount > 0, independent of whether the source observable has completed.
• When takeUntil emits, it completes the source; the shareReplay’s internal subscription ends. If refCount reaches zero, the Subject is unsubscribed and its buffer is discarded.
• If refCount stays >0 because another subscriber remains, the buffer persists and stale values can be emitted to new subscribers after migration.

Steps for this migration scenario

1. Identify all places that subscribe to the shareReplay stream (components, services, effects).
2. Ensure each subscription is torn down when the old version’s destruction signal fires (e.g., unsubscribe in ngOnDestroy or via takeUntil on the same signal).
3. After confirming no residual subscriptions, you can rely on the automatic buffer clear; no extra code is needed.
4. If step 1 reveals a subscription that cannot be guaranteed to end (e.g., a singleton service that lives for the whole app lifetime), wrap the shareReplay in a custom operator that exposes a reset() method:

function shareReplayWithReset(bufferSize, windowTime) {
  let subject;
  const shared = shareReplay(bufferSize, windowTime).pipe(
    multicast(() => {
      subject = new ReplaySubject(bufferSize, windowTime);
      return subject;
    }),
    refCount()
  );
  return {
    observable: shared,
    reset: () => { if (subject) subject = new ReplaySubject(bufferSize, windowTime); }
  };
}

Call reset() immediately after the destruction signal emits.

Missing diagnostic detail

Do any long‑lived parts of the application retain a subscription to the shareReplay after the destruction signal? If yes, you need the reset approach; if not, you can safely depend on refCount reaching zero.