Close loopholes by refining 1.9 and 2.5

[anthonyvdotbe]

In my opinion, there exists a pair of loopholes in rules 1.9 and 2.5. In order to close those, I propose to change the rules as follows:

§1.9:

Publisher.subscribe MUST call onSubscribe on the provided Subscriber prior to any other signals to that Subscriber. Moreover, if the Subscription was cancelled by the Subscriber during the execution of onSubscribe, it is REQUIRED that no further signals occur. Publisher.subscribe MUST return normally, except when the provided Subscriber is null in which case it MUST throw a java.lang.NullPointerException to the caller, for all other situations [1] the only legal way to signal failure (or reject the Subscriber) is by calling onError (after calling onSubscribe).

(Concerning this change, specifically how the Publisher would know that the Subscription was cancelled during the execution of onSubscribe, please refer to this comment)

§2.5:

If a Subscriber receives an onSubscribe signal while it already has an active Subscription, it MUST NOT call Subscription.request() and MUST call Subscription.cancel() on the given Subscription.

These changes guarantee that a Subscriber is able to properly fend off intruding Publishers while it already has an active Subscription.

[viktorklang]

RE 1.9

May I ask why this is a problem? (i.e. what's the loophole?)

RE: 2.5

Trying to avoid negative rules, how about:

If a Subscriber receives an onSubscribe signal while it already has an active Subscription, it MUST call—and only call—Subscription.cancel() on the given Subscription.

Thoughts @reactive-streams/contributors ?

[anthonyvdotbe]

May I ask why this is a problem? (i.e. what's the loophole?)

The purpose of this issue is to guarantee that, once a flow is established between a Publisher and a Subscriber, no other Publisher can disrupt that flow. In other words, that the Subscriber is guaranteed that any signal it receives, originates from the Publisher of its active Subscription.
However, without the change to 1.9, this cannot be guaranteed, since a disrupting Publisher is allowed to send an onComplete/onError signal as well.

Trying to avoid negative rules, how about:

If a Subscriber receives an onSubscribe signal while it already has an active Subscription, it MUST call—and only call—Subscription.cancel() on the given Subscription.

Yes, that wording is better, thanks.

[viktorklang]

@anthonyvdotbe Thanks for elaborating there. I'm not sure how we can fix this without breaking backwards compatibility.

[viktorklang]

Closing as wontfix due to incompatibility.