Second Subscription rule

[olotenko]

https://github.com/reactive-streams/reactive-streams-jvm/blob/master/tck/src/main/java/org/reactivestreams/tck/SubscriberWhiteboxVerification.java#L216-L219

This rule and this test make no sense.

Publisher is allowed to observe cancellation "eventually". Publisher is allowed to call onError or onComplete without receiving request. on* methods do not distinguish which Subscripiton it is for. So if the Subscriber receives two onSubscribe, it may still receive various on* that will break the specification. (One Publisher does onComplete another Publisher does onNext)

In other words, there is no defence against non-conformant Publisher, or the systems that permit such a racy subscription to happen.

[akarnokd]

First of all, Rule 1.3 requires serial signaling thus if a Subscriber is reused, the second Publisher is not allowed to signal until the onSubscribe call it issued has returned. Yes, a Publisher can ignore the cancellation and still signal onComplete - there is no defense for that in this setup. Now imagine there was a cancel confirmation happening anyway...

The test is there to verify if the proper cancellation is happening for at least the non-racing scenario and helps detecting certain type of reuse bugs.

Sometimes, you can safely reuse the same Subscriber, for example, in concatMap where the you can reset the internals in onComplete to receive a fresh onSubscribe. For flatMap though, you need individual inner Subscribers.

[olotenko]

I read 1.3 as pertaining to a single Publisher, not all Publisher s past, concurrent, and future. There is no way to enforce anything else, because the state transitions are internalized.

I agree it may be useful to signal cancel. I disagree that all Subscriber must do that extra check. Say, I can prove my inner Subscriber does not escape to the outside world, and is passed to a single Publisher at a time. I see no good reason to require such a Subscriber to fence itself off against non-conformant Publisher s or attempt to detect multiple concurrent invocations of onSubscribe.

[akarnokd]

I read your comments on that flatMap commit and not sure what the problem is.

Is it that the inner subscriber is failing the TCK because of it implements a relaxed ruleset? Just don't test it with the TCK then.

Is it trust issues regarding Flow.Publishers violating the spec? You have to decide to either trust all, distrust all or trust only your own implementations.

All in all the TCK lets you verify conformant behavior in a limited way and I don't think it should be removed just because someone's use case doesn't fit it.

[olotenko]

The inner subscriber can be written without that check. The runtime overhead is low, but the reasoning is harder when there are more things to think about.

The issue is that that rule does not improve Subscriber s life even if it implements it.

[akarnokd]

Then ignore it if you still see value in the other verification methods.

[akarnokd]

Oh, I see why the concern. Some of your project's own code wouldn't pass the TCK.

[olotenko]

There are several things that are done incorrectly in that project. But getting it to a better level requires a sensible set of rules.

[akarnokd]

The rules have been fine, although not optimal, since the release of the spec/api/TCK. Some properties of the spec/TCK can be worked around just as fine.

So what action do you think reactive-streams-jvm should take regarding your issue?

(On a side-note, I'd really like to know, were these free and voluntary contributions or were they written by people paid to be working on the project?)

[olotenko]

Regarding the legal status of the contributions to that other project - you better contact the owners of the project.

I think it would be satisfactory to downgrade the MUST to SHOULD or something. On our side we can pick the tests that we like, or implement the strict check, it is not that expensive, just quirky and not much help.

[viktorklang]

Given that it is illegal by spec to attach the same Subscriber instance twice, that is already a spec violation in itself.
Worth remembering is that the spec is between unknown Publisher-Subscriber combinations, if your Publisher implementation can do things differently by checking the runtime type of the Subscriber, then you are free to do as you want, as long as the different behavior cannot be observed when attaching a generic Subscriber.

[olotenko]

It is ok to require that no one expects arbitrary Publisher s and arbitrary Subscriber s to be reusable. Requiring that all Subscriber s disallow reuse (under the pain of being branded as the spec violators), is backwards.

[viktorklang]

@olotenko Publishers are reusable by spec. Regarding Subscribers, if you know that a Subscriber is reusable, and you can clearly tell when it is safe to be reused, then you are of course free to do so. This is the same situation as with Iterators, only when knowing strictly more than simple Iterator is it safe to call next once hasNext has returned false. (for instance, you might have some reset method on it)

[olotenko]

Sure. But you see the point, right? That the spec says "for all", whereas it should say "exists".

[rkuhn]

I can see what you mean when expanding the scope to all uses of these interfaces. The intended scope, as documented in the preamble, is to define behavior for the interaction of Publishers and Subscribers across boundaries, both async and organizational; the main goal is interoperability. This goal is only achieved by saying “all conforming implementations do X”, otherwise one implementor cannot rely on the behavior to be displayed by another implementation when plugged together by a third party.