takeUntil subscription still retaining observers after component teardown — diagnosis needed

Direct answers

1. Yes. shareReplay without refCount: true (the default in RxJS 7.0–7.3) retains its internal ReplaySubject and the upstream subscription indefinitely once the first subscriber arrives. When the last downstream subscriber (terminated by takeUntil) unsubscribes, the inner subscription to the source (e.g., interval) is not released.
2. No. Sharing one destroy Subject across multiple takeUntil operators is safe. Each takeUntil creates its own inner subscription to the notifier; the notifier’s next/complete only tears down the specific chain it’s piped into. The risk is incomplete teardown if the shared notifier never emits (e.g., ngOnDestroy not called), not premature completion.
3. Look for retained ReplaySubject and Subscriber (or SafeSubscriber) instances. After each destroy cycle, a heap snapshot filtered for “ReplaySubject” should show a constant instance count. A growing count — or a Subscriber still linked to the source observable (e.g., the interval timer closure) — confirms the leak lives in shareReplay’s internal subscription, not in the destroy subject.

Why the leak occurs

With shareReplay({ bufferSize: 1, refCount: false }) (the RxJS 7.0–7.3 default), the first subscription connects to the source and creates a ReplaySubject that replays the buffered value to late subscribers. That connection is never reference-counted. When your component’s takeUntil(destroy$) unsubscribes, the downstream chain tears down, but the shareReplay’s inner subscription to interval remains active, holding the timer callback and any buffered values in memory.

Fix

source$.pipe(
  shareReplay({ bufferSize: 1, refCount: true }), // or shareReplay(1) in RxJS 7.4+
  takeUntil(this.destroy$)
).subscribe(...);

With refCount: true, the shared observable becomes reference-counted: when the last downstream subscriber unsubscribes (via takeUntil), the inner subscription to the source is torn down.

Verification steps (run in your app)

1. Confirm RxJS patch version: npm list rxjs | grep rxjs@. RxJS 7.4+ defaults refCount to true when windowTime is omitted; earlier versions default to false.
2. Add a finalize log before shareReplay to see when the source subscription actually tears down:

   source$.pipe(
     tap({ subscribe: () => console.log('sub'), finalize: () => console.log('unsub') }),
     shareReplay({ refCount: true, bufferSize: 1 }),
     takeUntil(this.destroy$)
   ).subscribe(...);

3. In Chrome DevTools → Memory tab, take heap snapshots after each mount/destroy cycle. Filter for “ReplaySubject” and “Subscriber”. Instance counts should stay flat with refCount: true.
4. Optional: implement a SubscriptionTracker service that increments a counter in subscribe and decrements in finalize; assert zero after destroy.

One missing detail that changes the recommendation

What is your exact RxJS patch version (e.g., 7.2.3 vs 7.8.1)? If you’re on 7.4+, shareReplay(1) already enables refCount by default and the leak may not exist; if you’re on 7.0–7.3, the explicit { refCount: true } is required.