Does shareReplay's teardown function get called?

RxJS version: 5.5.2

Code to reproduce: This is more of a question so I don’t have a reproducible example.

Expected behavior: Same as above.

Actual behavior: Same as above.

Additional information: At first, I encountered what I thought was a bug with the shareReplay operator, but after finding an older issue that brought up the same concerns, I discovered that it was a misunderstanding on my part about how shareReplay was supposed to work.

However, in the process, I dug through some of the source code and now I have a question about the teardown logic in the shareReplay operator:

https://github.com/ReactiveX/rxjs/blob/e159578eda80a96bb68b83418f503428cc23aa7f/src/operators/shareReplay.ts#L43...L49

Since the shareReplay operator does not create its own Subscriber, it looks like that teardown logic isn’t getting attached to anything. Will the teardown logic ever get called?

Thanks for all the hard work!

[martinsik]

Is there any resolution on this issue? I’ve bumped into exactly the same thing yesterday and was wondering why it doesn’t work…

[cartant]

Actually, as the this context is already a Subscriber, the innerSub subscription seems unnecessary - the subscription to the ReplaySubject will be added to the Subscriber when this is passed to subscribe. Unsubscription from the subject will occur when the Subscriber is unsubscribed. So the implementation could be:

subject.subscribe(this);

this.add(() => {
  refCount--;
  if (subscription && refCount === 0 && isComplete) {
    subscription.unsubscribe();
  }
});

I was tempted to write a PR for this, but with everything of interest in a closure, I can’t see how to write an initial, failing test.

It’s also awkward as the unsubscription from the source can only occur if the source has completed - at which time the unsubscription is redundant. As far as I can see, the refCount is unnesessary. In fact, the entire teardown looks to be redundant, to me.