Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

replay subject should ignore emitted values after completion #4519

Closed
FDIM opened this issue Jan 31, 2019 · 7 comments
Closed

replay subject should ignore emitted values after completion #4519

FDIM opened this issue Jan 31, 2019 · 7 comments

Comments

@FDIM
Copy link

FDIM commented Jan 31, 2019

Bug Report

Seems like replay subject behavior is a bit inconsistent. If one subscribes before the subject completes, only values emitted until completion are sent to observers - all good. Now if I subscribe after it completes, it will replay all the values - even if they were emitted after subject completion.

Reproduction
https://stackblitz.com/edit/rxjs-fyepk5

import { ReplaySubject } from 'rxjs'; 

const ready = new ReplaySubject();
ready.next(1);
ready.complete();
ready.next(2);

ready.subscribe(x => console.log(x));

Current Behavior
1 and 2 are logged to console

Expected behavior
Only 1 should be logged

Environment

  • RxJS version: 6.3.3
@cartant
Copy link
Collaborator

cartant commented Jan 31, 2019

With no buffer size specified, the buffer size is infinite - not one.

@FDIM
Copy link
Author

FDIM commented Jan 31, 2019

Yes, I know that - but still, if the subject completes - why should it keep collecting values in the buffer?

@cartant
Copy link
Collaborator

cartant commented Jan 31, 2019

Because the default behaviour was not changed. If refCount is not specified and is not set to true the subscription to the source is not unsubscribed.

The behaviour is described here and in that PR's initial description. It's likely the case that the docs can be improved - as I was unable to determine how to express the overload signatures in the TSDoc - but I don't believe this is a bug. Feel free to change this issue to an improve-the-docs issue.

@FDIM
Copy link
Author

FDIM commented Jan 31, 2019

Thanks for technical details, but I'd argue that from API standpoint this seems to be a bug. Easily fixable in client code though so no big issue.

@cartant
Copy link
Collaborator

cartant commented Jan 31, 2019

We're well aware that there are two camps here: one deems it a bug; the other does not. However, the behaviour was not changed (back) by the above referenced PR, so this isn't a bug.

@cartant cartant closed this as completed Jan 31, 2019
@FDIM
Copy link
Author

FDIM commented Jan 31, 2019

Not sure why you keep referencing the PR, it's not in 6.3.3. A discussion and a change in the future may be nice - so maybe the issue could stay open

@cartant
Copy link
Collaborator

cartant commented Jan 31, 2019

That PR is in 6.4 which has just been released.

A discussion and a change in the future may be nice - so maybe the issue could stay open

For the discussions that have been had - ad nauseam - see that PR and all of the issues it references.

As this issue relates to 6.3.3, it can stay closed as a dupe.

@lock lock bot locked as resolved and limited conversation to collaborators Mar 2, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants