Simon Baslé

got it, waiting to hear more from you then 👍

> Since we are moving to 3.3.x, which can include braking changes in terms of operators, I would appreciate migration to the mentioned solution. Can you expand on what the...

@OlegDokuka note `limitRequest` puts a hard **cap** on the request amount. With eg. `limitRequest(5)`, the following request pattern: ``` request(1) request(3) request(3) request(3) request(3) ``` is translated to: ``` request(1)...

@OlegDokuka the case where a downstream makes a lot of small requests and the `limitRate` operator is introduced with a higher `highTide` and `lowTide` in order to rebatch into larger...

bump @OlegDokuka: do you think you will have time to submit a PR?

IMO, you're pushing it too far for now with `filter`, `map`, `handle` and `doOnEach`, better stick with `doOn*` subset covered by `FluxPeek` for now...

FYI I've started toying around with the idea of macro fusion for `map`, `filter` and no `FluxPeek` (doOnSubscribe|Next|Complete|Error|Terminate|Request|Cancel and doAfterTerminate). ⚠️ For the later, something to keep in mind: when...

Any planned progress on this one @OlegDokuka ?

@maxim-bandurko-lsvt can you open an issue (`enhancement` type) to discuss the design and implementation of such an operator / variant of `limitRate` ? pursuing a generic solution the pagination problem...

> See also #1958 This seems to be a slightly different issue. Probable root cause is the fact that `ParallelSourceInner` cancels the whole source when an individual rail cancels. Here...