Unconsumed async exception in TCK?

[viktorklang]

From @Scottmitch:

"This feels like a problem in the TCK test harness

The root cause of the exception is "illegal argument to request n" which is generated during optional_spec309_requestNegativeNumberMaySignalIllegalArgumentExceptionWithSpecificMessage and that is expected. However the exception is detected asynchronously during running of a different test required_createPublisher1MustProduceAStreamOfExactly1Element which occurs during the subscribe operation (we haven't even requested data for this test). Seems like an async exception is not properly consumed in optional_spec309_requestNegativeNumberMaySignalIllegalArgumentExceptionWithSpecificMessage." - Source

[akarnokd]

I can't reproduce the issue with 0.21.0 of their library (example) and I can't build their library on Windows to check the latest unreleased code.

Looking at the exception stacktrace, the cause indicates the IAE was created on the test thread, which is odd:

Caused by: java.lang.IllegalArgumentException: Rule 3.9 states non-positive request signals are illegal, but got: -1315438106
	at io.servicetalk.concurrent.internal.SubscriberUtils.newExceptionForInvalidRequestN(SubscriberUtils.java:79)
	at io.servicetalk.concurrent.api.FromArrayPublisher$FromArraySubscription.request(FromArrayPublisher.java:70)
	at io.servicetalk.concurrent.api.ContextPreservingSubscription.requestSlowPath(ContextPreservingSubscription.java:59)
	at io.servicetalk.concurrent.api.ContextPreservingSubscription.request(ContextPreservingSubscription.java:51)
	at io.servicetalk.concurrent.reactivestreams.ReactiveStreamsAdapters$RsToStSubscriber$1.request(ReactiveStreamsAdapters.java:101)
	at org.reactivestreams.tck.TestEnvironment$ManualSubscriber.request(TestEnvironment.java:439)
	at org.reactivestreams.tck.PublisherVerification$24.run(PublisherVerification.java:927)
	at org.reactivestreams.tck.PublisherVerification.potentiallyPendingTest(PublisherVerification.java:1195)
	at org.reactivestreams.tck.PublisherVerification.potentiallyPendingTest(PublisherVerification.java:1190)
	at org.reactivestreams.tck.PublisherVerification.optionalActivePublisherTest(PublisherVerification.java:1167)
	at org.reactivestreams.tck.PublisherVerification.optional_spec309_requestNegativeNumberMaySignalIllegalArgumentExceptionWithSpecificMessage(PublisherVerification.java:922)

given that their subscribeOn should fail and deliver on the background thread:

java.lang.IllegalArgumentException: Rule 3.9 states non-positive request signals are illegal, but got: -100000
	at io.servicetalk.concurrent.internal.SubscriberUtils.newExceptionForInvalidRequestN(SubscriberUtils.java:79)
	at io.servicetalk.concurrent.api.FromArrayPublisher$FromArraySubscription.request(FromArrayPublisher.java:70)
	at io.servicetalk.concurrent.api.ContextPreservingSubscription.request(ContextPreservingSubscription.java:46)
	at io.servicetalk.concurrent.internal.TaskBasedSignalOffloader$OffloadedSubscription.run(TaskBasedSignalOffloader.java:250)
	at io.servicetalk.concurrent.api.ContextPreservingRunnable.run(ContextPreservingRunnable.java:43)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:834)

Looking at the code, there is a code path that when the executor fails, will try to issue the request on the caller thread:

https://github.com/apple/servicetalk/blob/master/servicetalk-concurrent-internal/src/main/java/io/servicetalk/concurrent/internal/TaskBasedSignalOffloader.java#L201

I don't see it in the log so not sure if it didn't happen or wasn't logged.

[viktorklang]

@akarnokd I think you're right, seems like it is an issue in how the executor works.

[Scottmitch]

given that their subscribeOn should fail and deliver on the background thread:

The test in question PublisherPublishOnOverrideTckTest only applies the publishOnOverride operator which delivers signals to Subscribers on another thread. It is expected that the Subscription thread is not modified from the calling thread.

I am also not able to reproduce locally with this reproducer on macOS or linux. Looks like the error handling in optional_spec309_requestNegativeNumberMaySignalIllegalArgumentExceptionWithSpecificMessage should block for a single exception before moving on which looks correct. We haven't seen the issue in a while but it is racy so I'll re-visit next time it occurs.

I can't build their library on Windows to check the latest unreleased code.

ServiceTalk now supports windows fwiw 🎉