requestOne with timeout causes multiple responses

Let’s say I have one client who makes a requestOne call that exceeds the specified timeout, the callback will be called when the timeout is exceeded, as well as when the subscriber responds:

Client:

nats.requestOne('help', '', {}, 1000, function(response) {

    if(response instanceof NATS.NatsError && response.code === NATS.REQ_TIMEOUT) {
        console.log('Request for help timed out.');
        return;
    }
    console.log('Got a response for help: ', response);
});

Subscriber:

nats.subscribe('help', {queue:'help-service'}, function(request, replyTo) {
    
    setTimeout(function() {

        nats.publish(replyTo, 'I can help!');

    }, 10000);
});

Notice that the Client’s timeout is 1s, but the Subscriber will take 10s to respond.

The client will output “Request for help timed out.”, then output “Got a response for help: I can help!”

The expected output should just be “Request for help timed out.”

[ColinSullivan1]

Just to add a few thoughts on this - while the client may behave as expected as it is today, if the client does not unsubscribe, it leaves a subscription on the server for the lifetime of the connection. With many requests, these subscription leaks will impact the server. While this can be general problem in client design outside of request/reply, it should be addressed here as @aricart noted, for sake of the server under typical request/reply usage.

[aricart]

Not quite sure that I understand what you are saying. So let me try here:

When you unsubscribe, locally the node client will remove its subscription mapping. If a message doesn’t have a matching subscription, it gets dropped. Since the node client is single threaded, when the unsubscribe is processed, the subscription is removed. If a new message is already in the buffer for the client during the unsubscribe, there’s no matching subscription when the message processing happens. Similarly if the server happens to forward a message before processing the unsubscribe, it is will get sent to the client, but the client should drop it.

In this case (the issue raised here), the subscription is still active on the client (and the server) until unsubscribe is called.