cover the allowed call sequences on Subscriber in a spec rule

[rkuhn]

Currently it is only implicit that legal sequences start with onError or onSubscribe and end with onComplete or onError (or not at all), and it is not regulated within the spec rules that onComplete is illegal before onSubscribe.

I see two ways to approach this:

• we leave the protocol sequence definition outside of the spec and add the missing rule about onComplete
• we make the sequence definition explicit within the rules

The second approach would lead to duplication, since legal sequence grammars are almost perfectly constrained already, so I am leaning towards adding a new rule that orders onComplete and onSubscribe.

[drewhk]

onComplete is currently legal before onSubscribe. I don't know how much you would gain by ordering them, given that onError can come before onSubscribe anyway. In my experience the only real help to implementors would be if onSubscribe is always the first message, even if it is immediately followed by onComplete or onError. Less state variations to maintain. I am not sure we want that though.

[rkuhn]

According to the docs the legal status of “onComplete first” is at least dubious, and #199 introduces a test that fails in this case, so we should definitely fix this either way.

[ktoso]

The spec (the rules) does not mandate if onComplete can come first or not currently, as mentioned in #199 and for more details see this comment

It is a bit accidental that current behaviour is "onComplete can not come first", as such is the diagram in section https://github.com/reactive-streams/reactive-streams#api-components which isn't really a spec rule.

[drewhk]

In the Akka impl we definitely treated onComplete as valid response instead of onSubscribe, in fact we have testkit methods like: expectCompletedOrSubscriptionFollowedByComplete()

[drewhk]

So the current language accepted by Akka Subscribers is:

(onSubscribe ~ (onNext)*)? ~ (onError | onComplete)

(Kleene star here allows infinite words)

[viktorklang]

@drewhk onError definitely needs to be able to be sent before onSubscribe if the Publisher is unable to, for some reason, create a Subscription.

[drewhk]

Well, you can always send a dummy subscription, but in general I agree. I don't see though then why cannot we send an onComplete instead of an onSubscribe. Since we need to handle the onError case the onComplete case is not that much to add (from an implementors perspective).

[viktorklang]

@rkuhn I agree with "so I am leaning towards adding a new rule that orders onComplete and onSubscribe.".

The question is if the symmetry of being able to send either onError or onComplete before onSubscribe has merit and should be instated (I'd think not, since it is ultimately racy for hot publishers)

[drewhk]

@viktorklang so you propose the following language?

(onSubscribe ~ (onNext)* ~ (onError | onComplete)) | onError

[viktorklang]

@drewhk Since it is verboten by the spec to call any methods on the Subscription from within onError or onComplete there should not be any technical issues with allowing both onError and onComplete without a preceeding onSubscribe.

Current semantics as present in the README.md: onError | (onSubscribe onNext* (onError | onComplete)?)

[viktorklang]

@reactive-streams/contributors Thoughts?

[drewhk]

My point (experienced in Akka Streams) is that if you have to handle onError without onSubscribe then it is not that hard to add onComplete handling there, too. I personally prefer what we use now:

(onSubscribe ~ (onNext)*)? ~ (onError | onComplete)

Not because I don't want to rewrite it, but because it makes sense. The simplest implementation wise of course would be:

onSubscribe ~ (onNext)* ~ (onError | onComplete)

but that would mean that the Publisher must send dummy Subscriptions even when it knows that it is already empty or in error state.

Edited