search

eclipse / microprofile-reactive-streams-operators

Microprofile project
Apache License 2.0
79 stars 33 forks source link

TCK: Coupled operator vs rule 2.3 #131

Open danielkec opened 4 years ago

danielkec commented 4 years ago

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 commented 4 years ago

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

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 commented 4 years ago

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 commented 4 years ago

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

danielkec commented 4 years ago

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

olotenko commented 4 years ago

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 commented 4 years ago

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: https://github.com/reactive-streams/reactive-streams-jvm/pull/483

Emily-Jiang commented 4 years ago

Waiting for Reactive Streams TCK release and then consume it.