Dariusz Jędrzejczyk

Please reopen if you manage to create a reproducer.

If you are able to identify the pipeline that causes this, please share. The stackoverflow might be just a side effect of an incorrectly crafted pipeline, e.g. assemblying a reactive...

I ran the above and I get a `java.lang.StackOverflowError` (SOE) with repeated: ``` at reactor.core.publisher.MonoFlatMap$FlatMapMain.request(MonoFlatMap.java:194) ``` or ``` at reactor.core.publisher.MonoFlatMap$FlatMapMain.cancel(MonoFlatMap.java:199) ``` Depending on the loop size chosen (5000, 10_000). It's...

Thank you for the report @jamiestewart 👍 I can confirm this is a bug in the existing implementation. I need to give it some thought about the next steps. There...

Thank you for the report. I can confirm this is a bug. I will investigate.

As a matter of fact, Automatic Context Propagation is not the root cause here. `Flux#refCount` combined with `Operators.lift` is problematic: For `Subscriber` of a `Fuseable` operator (`FluxMapFuseable`), it feeds a...

I dug a bit deeper. Two things: 1. The issue mentioned above is expected: wrapping a `Fuseable` `Subscriber` with a non-`Fuseable` one is prohibited. There is no way the internals...

One more issue is that `FluxRefCount`, being `Fuseable`, gets wrapped into a `FluxLiftFuseable` upon assembly, which upon creation takes the source `Publisher`, `FluxRefCount` and applies `Flux.from` on top of it....

I created a PR to address the multitude of problems that led to this report. @kz-dt I have a question. The answers won't influence the fix that is needed with...

@kz-dt thanks for sharing. I think I managed to resolve the possible issues. Please validate with the latest `3.6.6-SNAPSHOT`.