search

rsocket / rsocket-js

JavaScript implementation of RSocket
https://github.com/rsocket/rsocket-js
Apache License 2.0
594 stars 97 forks source link

[rx adapter] Requester.requestChannel - No actual subscription until first requester emission #233

Open MarcoScabbiolo opened 2 years ago

MarcoScabbiolo commented 2 years ago

Expected Behavior

client -> .requestChannel server -> receives .requestChannel server -> sends message 1 client -> receives message 1 client -> sends message 2 server -> receives message 2

Actual Behavior

client -> .requestChannel client -> sends message 1 server -> receives .requestChannel

Possible Solution

This looks intentional, there is some extra logic to do this in the code but I don't know why it is done this way. Receiving message before sending them sounds like a perfectly valid use case for me. https://github.com/rsocket/rsocket-js/blob/c6d6c4712fc137e3f1c5e5f9105936cdef83e5ca/packages/rsocket-adapter-rxjs/src/Requesters.ts#L133-L159

Why is this done? Wouldnt be better to subscribe right away, even if there is no initial payload?

OlegDokuka commented 2 years ago

Hi @MarcoScabbiolo!

This is indeed intentional. As per spec, the Request_Channel frame carries the first payload with it (metadata from which we extract route as well as data, thus we await the first element before initiating the call.

Technically, you can overcome that problem by sending an empty data element.

Alternativelly, we can technically introduce an overloaded method with first element as a parameter, so it can be null. In that case, you may have REQUEST_CHANNEL frame sent upon subscription without the wait for the first element.