Lost messages vulnerability when using `buffer` and `bufferTimeout` operators

[DavidDuwaer]

Vulnerability

When using batching operators, e.g. buffer and bufferTimeout, that return a Flux<List<T>>, put events in lists (not sure if I'm following the correct lingo here, but when I write "event" I mean the object of type "T" in a Flux<T>). In subsequent operators (e.g. .map or .onNext), elements can be removed from the list, leading to loss of events. While one should be free to pass Lists through Fluxes and Monos as if the List is the type of the event itself, having buffer and bufferTimeout return the List type encourages putting seperate events into lists.

Solution suggestion

• Making buffer and bufferTimeout return a Flux<Flux<T>> leverages the design of Flux operators that allow events to only be dropped either explicitly with .filter, or when an exception is thrown.
• More conservative is letting buffer and bufferTimeout return an ImmutableList. This makes sure subsequent .onNext operators can't touch it, but subsequent .map operators can still return a list that has implicitly dropped events.

[akarnokd]

This is not a vulnerability or even a bug. Those lists are free to get manipulated after they leave buffer. Imagine you can even add new events in doOnNext! You can wrap them into immutable datastructures after as you see fit via map.

Also there are the window operators already that return Flux<Flux<T>>.