Fix signal dispatching on RedisPublisher.request(…) #1837

RedisPublisher's NO_DEMAND.request(…) while switching to DEMAND now calls onDataAvailable(…) on the currently active state to ensure data signalling if there's (still) demand.

Previously, we called onDataAvailable(…) on the current NO_DEMAND state anticipating that if there's no data yet, then someone will read data from the channel and once it's there, we will be notified to emit it. Apparently, we can have data already in our buffer and so, upon requesting data, no one will notify us. Data was lingering in the publisher buffer and wasn't emitted. That caused downstream subscribers to hang indefinitely.

Data emission (and command completion) can happen when responses for a command. The request size doesn't correlate with the response that we receive from Redis. Redis can respond with less, exactly or more items. In case we receive from Redis more items than were requested, we buffer these to comply with RS back pressure semantics. After emitting the last requested item to the subscription, we switch from DEMAND (READING) to NO_DEMAND. And the issue exactly starts there.

We now call onDataAvailable(…) on the current state to ensure that when the state is DEMAND, that we will emit all data we have in our buffers.

src/main/java/io/lettuce/core/RedisPublisher.java

@@ -542,7 +542,7 @@ void request(RedisSubscription<?> subscription, long n) {
                     }
 
                     subscription.potentiallyReadMore();
-                    onDataAvailable(subscription);
+                    subscription.state().onDataAvailable(subscription);
                 } else {
                     onError(subscription, Exceptions.nullOrNegativeRequestException(n));
                 }