Ordering of onSubscribe and request signals will change depending on whether subscribeOn is called.

[paul-k-young]

These two blocks of code produce different orderings of the onSubscribe and request events.

    Flux.just(3,5,11)
        .log("step1")
        .map(x -> x*x)
        .log("step2")
        .collectList()
        .log("step3")
        .block();

    Flux.just(3,5,11)
        .log("step1")
        .subscribeOn(schedulerA)
        .map(x -> x*x)
        .log("step2")
        .subscribeOn(schedulerB)
        .collectList()
        .log("step3")
        .subscribeOn(schedulerC)
        .block();

The first block shows the following sequence:
step1: onSubscribe
step2: onSubscribe
step3: onSubscribe
step1: request
step2: request
step3: request

Whereas the second block shows this sequence:
step3: onSubscribe
step3: request
step2: onSubscribe
step2: request
step1: onSubscribe
step1: request

It appears that ordering of subscribeOn and request signals isn't guaranteed. That said, @smaldini suggested I raise the issue as it might adversely impact metrics.

Here's the test case with logs:
ReactorTest2.java.zip

[OlegDokuka]

@paul-k-young I guess we can nothing to do about it. This behaviors are there by design.

In Reactive Streams spec, there is a whole rule explaining that Subscriber#onSubscribe must be called from the Publisher#subscribe method (https://github.com/reactive-streams/reactive-streams-jvm#1.9) and there is a whole discussion with an intent to explicitly clarify that (reactive-streams/reactive-streams-jvm#494).

From that point, if onSubscribe is an async signal from the very first Publisher, there is a complete indeterminism and a black hole of concurrency problems that may appear as a result of letting the publisher sending a subscription asynchronously:

1. if Publisher does something like the following:

      Publisher.subscribe { subscriber -> 
          new Thread(() -> subscriber.onSubscribe(subscription)).start()
      }
   

   then, there is a whole possibility that the scheduled lambda will never be invoked (assume OutOfMemoryException which may simply crash only that Thread but not the others (just for reference -> https://stackoverflow.com/questions/3058198/can-the-jvm-recover-from-an-outofmemoryerror-without-a-restart) so that your subscriber will never know about the fact that the offloaded task has failed.
2. Having async subscription propagation implies the impossibility to cancel such subscription (operator like .timeout will never work anymore or will work with zero guarantees on termination time)

...Coming back to subscribeOn, shown in the second example...

Frankly speaking subscribeOn does kind of operation like new Thread(() -> upstreamPublisher.subscribe(SubscribeOnSubscriber)). So, here we stay at the point where we should notify our original subscriber about the subscription fact.

if we send subscription to the very bottom subscriber only when the very top publisher (in our case it is Flux.just(3,5,11)) is being subscribed, then we have to wait for 3 scheduling and in that case, we going to have the problem described above.

Thus, to avoid the problem, subscribeOn propagates subscription immediately on the caller Thread. That does not guarantee the order of when onSubscribe is being observed by the upstream but allows the actual subscriber to receive subscription immediately and being able to cancel the offloaded task at any point in time or request more data

Thus, to summarize, what you see in the logs is an expected behavior and if you need to know when the upstream is being subscribed, I suggest to use a different mechanism for that purpose