-
Notifications
You must be signed in to change notification settings - Fork 3k
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
buffer drops last buffer on source complete (again) #3990
Comments
It's unfortunate that #2174 wasn't merged into v6, but I guess the reasoning referenced in this comment still applies:
|
I'm still a bit confused (sorry for ignorance). So it was merged, but into the Reactivex:next branch, which I thought was for v6. Does this mean it's part of the next major release (v7)? I also can't see the next branch anymore. It seriously looks to me like this commit just got lost some how, it's really old (31st Jan 2017). It was tagged as 6.0.0-alpha.0 and even added to the list of bug fixes: 0b2ddf2 |
When v6 was released, I've done some investigating. The PR you referenced was merged into v6 ( https://github.com/ReactiveX/rxjs/blob/6.0.0-alpha.0/src/operator/buffer.ts And you can see the history for that file here: https://github.com/ReactiveX/rxjs/commits/6.0.0-alpha.0/src/operator/buffer.ts If you look at the source for the alpha release that follows the one you referenced, it seems that the commit and the one that followed in the above history were lost in the directory restructuring: https://github.com/ReactiveX/rxjs/blob/6.0.0-alpha.1/src/internal/operators/buffer.ts So I guess that none of the v6 releases that followed the first alpha have included either of those fixes. |
Aha, makes sense now. So it was lost in the directory restructuring. Well that's ok, it happens. Do we agree that this is still an issue and it will be addressed in the next release? For me losing "events" is a major issue so I'd really like this fix. Thanks for all the help thus far. I was really confused. |
If the commits got 'lost', I think they need to be reinstated - for v7 - as they'd already been deemed fixes. AFAICT, there was no reason for their being reverted. I'll have a closer look, later, at the commits that occurred between the two alpha releases - to see if I can better understand what happened. |
What we'll need is the tests from those commits, perhaps add them into the current test suite, but commented out with |
This is now waiting in the v7 branch |
In 61b1767, it doesn't look like any of the tests cover the following case:
|
…ingNotifier` active Gives the author control over the emission of the final buffer. If the `closingNotifier` completes before the source does, no more buffers will be emitted. If the `closingNotifier` is still active when the source completes, then whatever is in the buffer at the time will be emitted from the resulting observable before it completes. BREAKING CHANGE: Final buffered values will now be emitted from the resulting observable if the `closingNotifier` is still active. The simplest workaround if you want the original behavior (where you possibly miss values), is to add a `skipLast(1)` at the end. Otherwise, you can try to complete the `closingNotifier` prior to the completion of the source. Fixes ReactiveX#3990, ReactiveX#6035
…ingNotifier` active Gives the author control over the emission of the final buffer. If the `closingNotifier` completes before the source does, no more buffers will be emitted. If the `closingNotifier` is still active when the source completes, then whatever is in the buffer at the time will be emitted from the resulting observable before it completes. BREAKING CHANGE: Final buffered values will now be emitted from the resulting observable if the `closingNotifier` is still active. The simplest workaround if you want the original behavior (where you possibly miss values), is to add a `skipLast(1)` at the end. Otherwise, you can try to complete the `closingNotifier` prior to the completion of the source. Fixes ReactiveX#3990, ReactiveX#6035
…ingNotifier` active Gives the author control over the emission of the final buffer. If the `closingNotifier` completes before the source does, no more buffers will be emitted. If the `closingNotifier` is still active when the source completes, then whatever is in the buffer at the time will be emitted from the resulting observable before it completes. BREAKING CHANGE: Final buffered values will now be emitted from the resulting observable if the `closingNotifier` is still active. The simplest workaround if you want the original behavior (where you possibly miss values), is to add a `skipLast(1)` at the end. Otherwise, you can try to complete the `closingNotifier` prior to the completion of the source. Fixes ReactiveX#3990, ReactiveX#6035
BREAKING CHANGE: Final buffered values will now always be emitted. To get the same behavior as the previous release, you can use `endWith` and `skipLast(1)`, like so: `source$.pipe(buffer(notifier$.pipe(endWith(true))), skipLast(1))` Fixes ReactiveX#3990, ReactiveX#6035
Bug Report
Current Behavior
buffer drops last buffer on source complete.
Reproduction
https://stackblitz.com/edit/typescript-4rc7ej
Expected behavior
Environment
Possible Solution
The fix is almost the same as in #2174, due to breaking changes I just translated it to be compatible with rxjs6, t1bb4r@ed3c82d
Additional information
This bug has already been reported and fixed at some point, but it looks to me like the commit got lost between rxjs 5 and 6, because it's not on either of the two now. (again see #2174). I am now reporting that it is not working in rxjs 5 or 6.2.2 and I couldn't find any issues or pull requests removing this functionality.
The text was updated successfully, but these errors were encountered: