Skip to content

Commit abfbf98

Browse files
committed
Clarified the expected behaviour for triggerRequest
This addresses some of the problem raised in reactive-streams#280.
1 parent 9464664 commit abfbf98

File tree

1 file changed

+16
-1
lines changed

1 file changed

+16
-1
lines changed

Diff for: tck/src/main/java/org/reactivestreams/tck/SubscriberWhiteboxVerification.java

+16-1
Original file line numberDiff line numberDiff line change
@@ -789,8 +789,23 @@ public interface SubscriberProbe<T> {
789789
* make implement these calls.
790790
*/
791791
public interface SubscriberPuppet {
792+
792793
/**
793-
* Trigger {@code request(elements)} on your {@link Subscriber}
794+
* Ensure that at least {@code elements} are eventually requested by your {@link Subscriber}, if it hasn't already
795+
* requested that many elements.
796+
* <p>
797+
* This does not necessarily have to correlate 1:1 with a {@code Subscription.request(elements)} call, but the sum
798+
* of the elements requested by your {@code Subscriber} must eventually be at least the the sum of the elements
799+
* triggered to be requested by all the invocations of this method.
800+
* <p>
801+
* Additionally, subscribers are permitted to delay requesting elements until previous requests for elements have
802+
* been fulfilled. For example, a subscriber that only requests one element at a time may fulfill the request made
803+
* by this method by requesting one element {@code elements} times, waiting for each element to arrive before the
804+
* next request is made.
805+
* <p>
806+
* Before sending any element to the subscriber, the TCK must wait for the subscriber to request that element, and
807+
* must be prepared for the subscriber to only request one element at a time, it is not enough for the TCK to
808+
* simply invoke this method before sending elements.
794809
*/
795810
void triggerRequest(long elements);
796811

0 commit comments

Comments
 (0)