shareReplay({ refCount }) after upgrading to RxJS 7: old buffered values still replayed to new subscribers

Short answer

With shareReplay({ bufferSize: 1, refCount: true }) in RxJS 7, the buffer is only discarded when the subscriber count actually falls to zero. If even one subscriber stays alive, the internal ReplaySubject persists, and every later subscriber receives the previously buffered value before any fresh emission. So the stale-replay symptom almost always means your stream never truly reaches zero subscribers — not that RxJS 7 changed the reset semantics against you.

Likely explanation vs. confirmed behavior

Confirmed for RxJS 7's config-object form:

• refCount: true: when the last subscriber unsubscribes, the source subscription is torn down and the next subscription creates a fresh ReplaySubject — the buffer is cleared.
• refCount: false (default): once started, the source subscription and buffer live indefinitely.
• A terminated (errored/completed) ReplaySubject replays its terminal state to later subscribers; it does not resubscribe to the source.

Likely explanations for what you're seeing, in order of probability:

1. A long-lived subscriber (root component, singleton service, or a subscription without takeUntil/async pipe) keeps the count above zero, so the reset never fires.
2. Migration changed the shape of the code: RxJS 6's shareReplay(1) had no refCount at all, and teams often paired it with publishReplay(1) + refCount() or the deprecated shareReplay({ refCount: true }) overload — which in 6.x had a known leak where the ReplaySubject was not released. If you mechanically rewrote to the 7.x config object, the reset timing may differ from what the old pipeline actually did.
3. Multiple shareReplay instances: if the operator sits inside a factory function that gets re-invoked, each call creates its own buffer, and a leaked instance can outlive its subscribers.

Using share() config instead

RxJS 7's reworked share() accepts resetOnError, resetOnComplete, and resetOnRefCountZero, each taking a boolean or a factory returning an observable (e.g., a timer) that controls when the shared subject is recreated. If you want explicit reset-on-error plus reset-on-refCount-zero semantics, share({ connector: () => new ReplaySubject(1), resetOnError: true, resetOnRefCountZero: true }) gives you the equivalent of shareReplay({ bufferSize: 1, refCount: true }) with error recovery — something shareReplay alone does not offer.

How to verify in your app

Instrument the source to see whether teardown ever happens:

const shared$ = this.http.get(url).pipe(
  tap(() => console.log('source subscribed / re-executed')),
  finalize(() => console.log('source torn down')),
  shareReplay({ bufferSize: 1, refCount: true })
);

If "source torn down" never logs before the next subscriber arrives, the count never hit zero — hunt for the leaked subscription. Also tag emissions with a request id or timestamp to distinguish "replayed old buffer" from "source re-executed but the HTTP layer returned cached data." A quick unit test — subscribe, unsubscribe all, resubscribe, assert the source re-runs — confirms operator behavior independent of your components.

One detail worth checking before changing code: run npm ls rxjs and confirm the exact minor version, since windowTime and reset behavior have subtle version-sensitive edges. If teardown logs correctly and stale values still appear, the most probable culprit is a second shareReplay instance holding its own buffer.