An Angular service polls feature flags with timer, switchMap and shareReplay(1), and polling continues after every subscribing component is destroyed; why, and what does refCount: true change?

## The setup A feature-flag service wants fresh flags every 30 seconds and one shared stream for all components: ```ts import { Injectable, inject } from '@angular/core'; import { HttpClient } from '@angular/common/http'; import { shareReplay, switchMap, timer } from 'rxjs'; @Injectable({ providedIn: 'root' }) export class FeatureFlagService { private readonly http = inject(HttpClient); readonly flags$ = timer(0, 30_000).pipe( switchMap(() => this.http.get<Record<string, boolean>>('/api/flags')), shareReplay(1), ); } ``` Components read `flags$` with the `async` pipe. When the user navigates away and every such component is destroyed, the network panel still shows a request every 30 seconds. ## Why the source keeps running `shareReplay` sits between one **source** and many **subscribers**. It keeps an internal **reference count**: the number of current subscribers. - The first subscriber makes it subscribe to the source (the connection). - Later subscribers attach to the internal `ReplaySubject`. - When subscribers unsubscribe, the count goes down. What happens at **zero** is controlled by `refCount`. In RxJS 7.8 the default is `false`: the connection to the source is **kept**. The components did unsubscribe correctly (the `async` pipe unsubscribes on destroy), but they unsubscribed from the shared stream, not from the source. The source subscription belongs to `shareReplay`, and with `refCount: false` it never lets go. A `timer` never completes, so in a root service that lives as long as the app, polling never stops. RxJS documents this default deliberately: `shareReplay` is often used to keep an expensive setup alive between subscribers. ## What refCount: true changes ```ts shareReplay({ bufferSize: 1, refCount: true }) ``` 1. When the count drops to zero, the source is **unsubscribed**: the timer stops and an in-flight request is cancelled by `switchMap`'s teardown. 2. The next subscriber gets a **new** internal `ReplaySubject` and a **new** source subscription. 3. `timer(0, ...)` fires immediately, so the new subscriber gets fresh flags rather than the stale buffered value. The cost is re-work: if consumers appear and disappear often (a flag-dependent widget in a route that users flip between), each gap causes a new first request. ## Completed sources are the exception `shareReplay` is built on `share()` with `resetOnComplete: false`, and the refCount reset only applies while the source is still active. | Source | refCount: false | refCount: true | |---|---|---| | Never-completing (timer, WebSocket, a stream derived from a BehaviorSubject) | source runs forever after the last subscriber | source torn down at zero, restarted on next subscribe | | Single HttpClient GET, response already arrived | value cached for the Observable's life | value cached for the Observable's life | | Single HttpClient GET, all subscribers leave before the response | request finishes and the response is cached | request cancelled; next subscriber sends a new one | So "always add `refCount: true`" is not a rule; it matters for sources that stay active. ## Middle ground: a grace period `share()` accepts a function for `resetOnRefCountZero`, which delays the teardown: ```ts share({ connector: () => new ReplaySubject(1), resetOnError: true, resetOnComplete: false, resetOnRefCountZero: () => timer(5_000), }) ``` If a new subscriber arrives within five seconds, for instance the next route's component, the source keeps running and no restart occurs. ## How to diagnose it - Add `tap({ subscribe: ..., finalize: ... })` around the source to log when it is subscribed and torn down. - Look for `shareReplay(1)` or `shareReplay(n)` on any source that does not complete. - Remember that the leak is not only memory: here it is steady network traffic and server load. ## Other sources that hit the same trap The polling timer is the clearest case, but any source that never completes behaves the same way under `shareReplay(n)` with the default setting: - a stream derived from a service's own `BehaviorSubject`, which also keeps whatever it closes over alive, - `Router.events` or a form control's `valueChanges` piped through a shared operator in a service, - a WebSocket or server-sent-events wrapper, - `fromEvent(window, 'resize')` shared across components. For each, ask two questions when reviewing: does this source complete on its own, and should it keep running when nobody is listening? If the answers are "no" and "no", the sharing operator needs `refCount: true` or an equivalent `share()` configuration.