TCK: Coupled operator vs rule 2.3

[danielkec]

Coupled operator needs to signal cancel to parallel stream's upstream on its completion, but rule 2.3 forbids direct call from onComplete to cancel. Since the streams are actually parallel is the rule 2.3 and its tck test actually applicable? Same goes from onError->cancel call.

There was already discussion on https://gitter.im/eclipse/microprofile-reactive#

[Azquelt]

I don't think this violates 2.3 because you're not calling cancel() on the subscription from the publisher which sent the onComplete().

I'm not sure what you mean by "parallel" stream. As I read it, the couple operator is a processor (and therefore has an upstream and a downstream), when you create it, you pass in a Subscriber sub and a Publisher pub. The couple then passes elements from upstream to sub and elements from pub to downstream.

In the scenario you're talking about, upstream has called onComplete and the couple has to

• call onComplete on sub
• call cancel on the subscription from pub
• call onComplete on downstream

I think rule 2.3 would only apply if you were to try to call cancel on the subscription received from upstream, which the spec does not require you to do.

[danielkec]

Yes but TCK test for rule 2.3 doesn't care about originating stream, it just looks for method called "onComplete" in call stack. Rule 2.3 should not be applied to coupled processor because its publisher and subscriber are not subscribed to each other right?

[cescoffier]

@danielkec Agreed. We need to fix that in the TCK, or if possible improve the detection.

[danielkec]

Related issue: reactive-streams/reactive-streams-jvm/issues/460

[olotenko]

I wonder how they are going to enforce rule 2.3 at all. Subscriptions are meant to be used concurrently. Plenty of rules specifically allowing request and cancel to be called synchronously, and references to possibility of request or cancel and onNext to be on different threads. All this implies it may well be during onComplete.

Rule 1.6 is the rule that makes sense. Once onError or onComplete is entered, the Subscription is as good as cancelled. There are several rules that require the Subscription to behave as no-op after it is cancelled.

In other words, 2.3 is moot.

[akarnokd]

The TCK checked for any method named onError or onComplete in the stacktrace when a call was made to request or cancel, even though those originated from another thread or before the test itself called onComplete or onError.

Fix posted to the TCK: reactive-streams/reactive-streams-jvm#483

[Emily-Jiang]

Waiting for Reactive Streams TCK release and then consume it.