Can't make TCK IdentityProcessorVerification test 3.12 pass

[danarmak]

I'm trying to make my implementation pass the 0.4.0 TCK (as published on Maven). Currently all PublisherVerification and SubscriberBlackboxVerification tests pass, and all IdentityProcessorVerification tests except for two, which fail for the same reason.

The simpler of the two failing tests is spec312_cancelMustRequestThePublisherToEventuallyStopSignaling. It fails with the error:
Did not receive expected cancelling of upstream subscription within 1000 ms.

Looking at the code, this times out waiting for ManualPublisher.cancelled.close() to be called. AFAICT this is only called by various TCK code implementing Subscription. I don't see how my implementation can influence when these TCK methods are called. Presumably the TCK is supposed to call Subscription.cancel on both my own implementation of Subscription (which happens), and on the TCK's implementation here, which apparently doesn't.

The other failing test is exerciseWhiteboxHappyPath, which does something similar to spec312 only more complex.

I haven't read the TCK code closely enough to be sure what the problem is. I'm hoping you can help me with this.

[viktorklang]

Hi @danarmak,

More information is needed.

[danarmak]

Hi @viktorklang,

I added log statements everywhere and ISTM that this test is expecting my Processor to cancel its upstream subscription after the downstream one is canceled. Which my code doesn't do, as discussed in #114.

However, that doesn't seem to have anything to do with rule 3.12 (publisher must eventually stop signalling after subscription is canceled), so I might be wrong. What is this test supposed to check and how?

The log statements show this sequence of events:

• helperPublisher method creates a Publisher. Someone subscribes to it and requests one element, it publishes the element 1, and nothing more is requested from this Publisher again. AFAICS it's not really used in this test, it's probably just created due to generic TCK setup code.
• identityProcessor is created. It gets calls to be subscribe and onSubscribe (not from the helpPublisher), and confirms the downstream request by creating a Subscription and calling onSubscribe. It never gets a call to Subscription.request.
• The Subscription created by the identityProcessor's gets a call to cancel.

At this point my code just sat and did nothing, and eventually the TCK timed out with the error Did not receive expected cancelling of upstream subscription within 1000 ms.

I modified my code to cancel the upstream subscription after the downstream one was canceled, and the test passed.

[viktorklang]

@danarmak I think you are right https://github.com/reactive-streams/reactive-streams/blob/9a6df52485ee18aacd1288ccf38ecbc35452ec88/tck/src/main/java/org/reactivestreams/tck/SubscriberWhiteboxVerification.java#L436 does not verify 3.12.

3.12 is about if the Subscriber has asked for X and signals cancel after X-Y elements, at some point the Publisher needs to acknowledge the cancellation by not sending more elements.

[viktorklang]

Ping @ktoso

[ktoso]

Hi guys, sorry for the delay; I was on holiday, traveling a lot.
Great catch @danarmak thanks for noticing, the test is indeed not testing what it claims it does.
I'll give it a shot to rework the test to check what it actually should and submit a PR today.

[ktoso]

Addressed this problem in PR #121, it's actually a Publisher behaviour, so I have moved it out there. Please have a look guys.

[danarmak]

I'm going on a trip and I won't have time to test the PR until the 15th or so, so you don't have to wait for me if you want to merge this.