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

[MarcoScabbiolo]

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.

rsocket-js/packages/rsocket-adapter-rxjs/src/Requesters.ts

Lines 133 to 159 in c6d6c47

	const [firstValueObservable, restValuestObservable] = partition(
	datas.pipe(
	share({
	connector: () => new Subject(),
	resetOnRefCountZero: true,
	})
	),
	(_value, index) => index === 0
	);
	return (
	rsocket: RSocket,
	metadata: Map<string | number | WellKnownMimeType, Buffer>
	) =>
	firstValueObservable.pipe(
	take(1),
	concatMap(
	(firstValue) =>
	new Observer2BufferingSubscriberToPublisher2PrefetchingObservable(
	(
	s: OnTerminalSubscriber &
	OnNextSubscriber &
	OnExtensionSubscriber &
	Requestable &
	Cancellable
	) =>
	rsocket.requestChannel(

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

• RSocket version(s) used:

"rsocket-adapter-rxjs": "1.0.0-alpha.2",
"rsocket-core": "1.0.0-alpha.1",

[OlegDokuka]

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.