shareReplay({ refCount: true }) has different behavior with share()

[loadingwyn]

Describe the bug

Hello, I tried the example given by https://medium.com/volosoft/whats-new-in-rxjs-7-a11cc564c6c0

import { interval, of, zip } from "rxjs";
import { map, shareReplay } from "rxjs/operators";

const shared$ = zip(interval(1000), of("A", "B", "C", "D", "E")).pipe(
  map(([, char]) => char),
  shareReplay({ refCount: true, bufferSize: 3 })
);

shared$.subscribe(a => console.log('a: ', a);
// (~1s apart)a:  A, B, C, D, E
setTimeout(() => shared$.subscribe(b => console.log('b: ', b), 6000);
// (after ~6s, all at once)b: C, D, E

I thought 'b' subscription would output 'A, B .... E' again. Because 'a' sub has completed in 5000ms, refCount should become 0. And then shared$ disconnects to the source. So when b subscribes shared$, the source would restart. But the console showed only 'C, D, E' replayed by shareReplay.

If I replace shareReplay({refCount: true}) with share() or add take(5) to 'a', b will ouput as I expect.

Expected behavior

shareReplay({refCount: true}) should unsub like share()

Reproduction code

No response

Reproduction URL

https://stackblitz.com/edit/azerz8?devtoolsheight=50

Version

7.1.0

Environment

No response

Additional context

No response

[voliva]

I think it's as per design. Note that the medium article says how there's no need for shareReplay anymore: i.e. all/most of the overloads with shareReplay you should be able to do with share. But doesn't say that shareReplay({ refCount: true }) would have to behave the same way as share.

The docs for shareReplay say:

This operator is a specialization of replay that connects to a source observable and multicasts through a ReplaySubject constructed with the specified arguments. A successfully completed source will stay cached in the shareReplayed observable forever, but an errored source can be retried.

And this explains why if you add in a take(3) to the first subscription it works as you expect it to: In that case, the observable doesn't complete, but refCount goes to 0 => All subscriptions are cleaned up and the state is reset. But if you let it complete (without putting a take(3)), then it completes, so per that description of the operator the result stays cached forever.

If I replace shareReplay({refCount: true}) with share() or add take(5) to 'a', b will ouput as I expect.

If you replace it with share() I don't think it will work as you wanted, right? shareReplay also replays the last N (default=infinity) emissions when a new observer comes. I think it can be replaced with the following config:

share({
    connector: () => new ReplaySubject(),
//    resetOnComplete: true,
//    resetOnError: true,
//    resetOnRefCountZero: true
})

I commented out the configs that by default are true (they already have the value you are looking for, so you can just omit them).

On the other hand, shareReplay({ refCount: true }) has the following equivalent share+config (if I'm not wrong):

share({
    connector: () => new ReplaySubject(),
    resetOnComplete: false,
    resetOnError: false,
    resetOnRefCountZero: false
})

[loadingwyn]

Thank you very much. It really solves my problem. I think I need to be more careful when I use shareReplay. It has a lot of behaviors

[kwonoj]

I moved this into discussions and appreciate @voliva for the detailed explanations.