Sage Pierce

FWIW I have experienced a similar hanging behavior in groupBy, and may be related to [this issue](https://github.com/reactor/reactor-core/issues/2352). That issue is more talking about silently dropped onNext signals, but I think...

Yes, you would be losing concurrency, especially due to the blocking `sleep` in `concatMap`. Would only be mitigation and not solution, IMO

I think I've isolated this particular unexpected behavior to being the result of a race condition in `FluxGroupBy` between draining and cancellation on `UnicastGroupedFlux`. I think I've figured a workaround...

Thank you for the comments and suggestions, @bsideup! > you seem to be blocking the non-blocking threads. Maybe you wanted publishOn, not subscribeOn before doOnNext? I'll update the failure scenario...

> I still see .subscribeOn(scheduler, true) in the code - is it intentional? The problem is that you're blocking the parallel scheduler Yes, the `subscribeOn` is intentional such that `groupBy`...

FWIW, code without `subscribeOn`: ```java @Test public void test() throws Exception { // Hooks.onNextDroppedFail(); // This actually has no effect; Was thinking it would cause failure with CancelException AtomicLong upstream...

@bsideup I'll go ahead and add the `publishOn`, however I'm not certain I understand the value it provides as far as diagnosing the issue 🤔 I feel like it would...

@simonbasle I'm not sure I can say this isn't still an issue. Even with Reactor `3.4.12` I can still observe silently dropped emissions with the following simplified example: ```java @Test...

@Fokko I can confirm this is still an issue with Avro 1.9.2 and Jackson versions 2.9.8, 2.9.10, and 2.10.2

FWIW, @baharclerode the issue you brought up about nested class name deserialization breaking with Avro [1.9.0, 1.10.0) may have been fixed in ~1.10.0~ (actually, looks like it may not have...