[johnnyhuirilef]

PR Checklist

• The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

• Bugfix

What is the current behavior?

Issue Number: #17994

Closes #17994

Hi! 👋 This is the follow-up to #17959, which fixed the same problem in ClientNats.

A custom deserializer that throws or rejects on a reply crashes the process. ClientTCP, ClientRedis, ClientMqtt and ClientRMQ await the deserializer inside a listener that nobody awaits. The rejection is unhandled, so Node exits. If the app handles it, the request never settles.

I ran the repro on 12.1.2 with real brokers. All four clients crashed with exit code 1 on that reply:

RESULT: BUG: 4 of 8 cases did not end as expected (a crashed client exits with code 1).

The default deserializer never throws, so only a custom deserializer triggers this.

What is the new behavior?

ClientRMQ catches the error and fails the exact request with it. The callback gets the error and isDisposed, as in ClientNats. The RMQ reply consumer also ignores the null message that RabbitMQ sends when it cancels the consumer, as ServerRMQ does. The client logs a warning in that case, because the pending requests can no longer get a reply.

ClientTCP, ClientRedis and ClientMqtt catch the error, log it and drop the reply. Only the deserializer knows the request id, so these clients cannot tell which request to fail. The other pending requests stay as they are.

The same repro against a local build of this branch:

RESULT: FIXED: no client crashed, and RMQ failed the request with the deserializer error.

The four valid replies still resolve with "ok".

Does this PR introduce a breaking change?

• Yes
• No

Valid replies take the same path as before. Nothing exported changes.

Other information

The specs cover these cases:

• A deserializer that throws, and one that rejects.
• ClientRMQ: the request fails with the error, and the client removes the request from routingMap.
• ClientTCP, ClientRedis, ClientMqtt: the client logs the error and keeps the other pending requests.
• An error from the request callback is not caught by the new try.
• ClientRMQ: a null message from the broker does not throw, and the client logs a warning.
• The specs check the exact log message.

Some limits stay:

• On TCP, Redis and MQTT, the request that the rejected reply belonged to still waits, because the client cannot know its id. Nest sets no default request timeout. The RxJS timeout() operator on the caller side ends the wait and frees the request.
• A deserializer that returns undefined instead of throwing still fails outside the new try.
• ClientKafka has the same missing catch. kafkajs awaits the handler, logs the error and rethrows it to its own runner. I did not run that case, so I left it out of this PR.

I am happy to look at a better option for any of these if you have one in mind. 🙂

[Asadshah7950]

I pulled this down and verified the fix locally across all 4 microservice client suites (213 tests passing).

The crash it fixes is real. Because event callbacks like socket data listeners and message handlers run unawaited in the event loop, an unhandled rejection inside deserializer.deserialize() causes Node to exit with code 1.

A few things I like about this implementation:

1. Transport-aware separation:

   • In ClientRMQ, correlation is tracked at the envelope level via msg.properties.correlationId. Because callback is already bound to the pending request, the catch block can cleanly fail that specific caller with { err: error, isDisposed: true } and clean up routingMap.
   • In ClientTCP, ClientRedis, and ClientMqtt, the correlation ID lives inside the payload itself. When the deserializer fails, the client can't know which request the message was meant for. Dropping the bad packet and logging with this.logger.error(...) prevents the crash without risking corrupted state in other pending requests.

2. RabbitMQ consumer cancellation:

   • Adding if (!msg) in ClientRMQ.consumeChannel() handles the null delivery that RabbitMQ sends when a queue is deleted or cancelled, so we don't throw an uncaught TypeError on msg.properties.

3. Narrow try/catch scope:

   • The try/catch specifically wraps this.deserializer.deserialize() and nothing downstream. If subscriber code inside callback() throws, it isn't swallowed by this catch block. I verified this with the callback failure tests.

4. Non-blocking note on request cleanup for TCP/Redis/Mqtt:

   • For TCP, Redis, and MQTT, because dropped packets can't be mapped back to an ID, the caller's request will stay in routingMap until the caller's RxJS timeout() fires. That's the right tradeoff since guessing the ID would be dangerous.

Clean fix and thorough test coverage across all transports. LGTM!