Receive responses from multiple subscribers for a single request

[scottf]

One of the most common questions we get is how to do request-reply but get response from all subscribers, not just the first one. Currently the way to do it is publish a message with a reply-to and at the same time to subscribe to the reply-to address.

Since this is such a common ask, we should consider how to add it to the clients.

[ripienaar]

Cli has --replies for this purpose, so will unassign myself.

[aricart]

The javascript client handles this via the requestMany() apis.

[tbeets]

Agree @scottf. Although easy for developer to hand-roll, scatter-gather comes up often enough that a library-provided facility like @aricart describes makes sense.

I think the usual push back is useful options for "get response from all subscribers", i.e. timer based, count based (with expiry), etc. What tactic used for requestMany() @aricart ?

[wallyqs]

Also need to consider using the single resp mux to keep track of responses as an alternative to creating an inbox subscription for the batch of requests.

[ColinSullivan1]

Adding a convenience API would be nice - # of responses to expect, timeout, and return an array/list/slice of messages. This is a very common ask...

[aricart]

@tbeets you have several strategies:

• Timer
• Count
• Sentinel Message
• Jitter Timer

The jitter is the secret sauce, when you specify that, as long as messages are arriving, the jitter is reset (100ms or so). So this means you make a request with a 2s timeout, but as soon as you get one response, the jitter timer takes over and is reset with each new message. If no messages arrive within the jitter, then the request is done. With jitter most count/expected type things work correctly without having an absolute stop timer

Sentinel, is empty payload

The API works with both mux and no mux inboxes

[aricart]

https://nats-io.github.io/nats.deno/interfaces/NatsConnection.html#requestMany

[scottf]

Closing as being addressed with ADR