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

buffer drops last buffer on source complete (again) #3990

Closed
t1bb4r opened this issue Aug 3, 2018 · 9 comments · Fixed by #6042
Closed

buffer drops last buffer on source complete (again) #3990

t1bb4r opened this issue Aug 3, 2018 · 9 comments · Fixed by #6042
Assignees
Labels
bug Confirmed bug

Comments

@t1bb4r
Copy link

t1bb4r commented Aug 3, 2018

Bug Report

Current Behavior
buffer drops last buffer on source complete.

[0, 1, 2, 3, 4, 5, 6, 7, 8]

Reproduction
https://stackblitz.com/edit/typescript-4rc7ej

const tick = interval(100).pipe(take(15))

tick.pipe(buffer(interval(1000)))
  .subscribe((x) => console.log(x))

Expected behavior

[0, 1, 2, 3, 4, 5, 6, 7, 8]
[9, 10, 11, 12, 13, 14]

Environment

  • Runtime: Node v8.11.2
  • RxJS version: 6.2.2

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.

@cartant
Copy link
Collaborator

cartant commented Aug 4, 2018

It's unfortunate that #2174 wasn't merged into v6, but I guess the reasoning referenced in this comment still applies:

Looks good, but even though we didn't intend for the existing behavior, since we shipped it people could be relying on it.

Merge into next major release, not minor because it is a BREAKING CHANGE.

@t1bb4r
Copy link
Author

t1bb4r commented Aug 5, 2018

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

@cartant
Copy link
Collaborator

cartant commented Aug 5, 2018

When v6 was released, master was renamed to stable and next became the master. There is no current next branch; work for v7 is in experimental.

I've done some investigating. The PR you referenced was merged into v6 (next). You can see the source for the release you mentioned here:

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.

@cartant
Copy link
Collaborator

cartant commented Aug 5, 2018

Given that both #2174 and #2175 were breaking changes, I guess - for the same reasoning they weren't merged in v5 - they'll need to go into v7, now.

/cc @benlesh

@t1bb4r
Copy link
Author

t1bb4r commented Aug 6, 2018

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.

@cartant
Copy link
Collaborator

cartant commented Aug 6, 2018

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.

@benlesh
Copy link
Member

benlesh commented Aug 8, 2018

What we'll need is the tests from those commits, perhaps add them into the current test suite, but commented out with // FOR v7 or something like that? At some point, all of the tests need to be ported over to the experimental branch

benlesh added a commit that referenced this issue Sep 26, 2018
@benlesh
Copy link
Member

benlesh commented Sep 26, 2018

This is now waiting in the v7 branch

@t1bb4r
Copy link
Author

t1bb4r commented Sep 27, 2018

In 61b1767, it doesn't look like any of the tests cover the following case:

  it('should emit last buffer if source completes', () => {
    const a =    hot('-a-b-c-d-e-f-g-h-i-|');
    const b =    hot('-----B-----B--------');
    const expected = '-----x-----y-------(z|)';
    const expectedValues = {
      x: ['a', 'b', 'c'],
      y: ['d', 'e', 'f'],
      z: ['g', 'h', 'i']
    };
    expectObservable(a.pipe(buffer(b))).toBe(expected, expectedValues);
  });

@benlesh benlesh added the bug Confirmed bug label Feb 22, 2021
@benlesh benlesh self-assigned this Feb 22, 2021
benlesh added a commit to benlesh/rxjs that referenced this issue Feb 22, 2021
…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
benlesh added a commit to benlesh/rxjs that referenced this issue Feb 22, 2021
…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
benlesh added a commit to benlesh/rxjs that referenced this issue Feb 22, 2021
…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
benlesh added a commit to benlesh/rxjs that referenced this issue Feb 23, 2021
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
benlesh added a commit that referenced this issue Feb 24, 2021
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 #3990, #6035
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Confirmed bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants