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

shareReplay caching behavior across the RxJS 6 to 7 boundary

We cache an HTTP response with shareReplay so multiple components share one request. After upgrading from RxJS 6 to 7, we want to move from the legacy shareReplay(1) form to the documented configuration object shareReplay({ bufferSize: 1, refCount: true }), mainly so the source subscription is torn down when the last subscriber leaves.

The uncertainty is about what happens to the buffer itself. My understanding is that refCount: true unsubscribes from the source at zero subscribers, but the internal ReplaySubject buffer may not be cleared, so a subscriber arriving later could still receive the previously buffered (now stale) value before any fresh emission. I also understand that once the source errors, the ReplaySubject is terminated and later subscribers receive the cached error rather than triggering a new subscription.

RxJS 7 reworked share() with a configuration object and aligned shareReplay with it, so the reset semantics may differ from what we relied on in 6.x.

• With refCount: true, is the buffer guaranteed to persist after teardown, or does RxJS 7 reset it?
• Is there a documented way to get reset-on-error and reset-on-refCount behavior via share() config instead?
• Do these semantics differ between 6.x and 7.x in a way that affects migration?