NestJS 12.1.1 fixes reconnects in five microservice transports
Victoria Shinder1 min readNestJS, the Node.js server framework, published version 12.1.1 on 28 September. Most of the fixes in the release notes concern the microservices package and one theme: what happens to a client when its connection fails or is replaced.
The MQTT and RabbitMQ clients can now retry after a failed connect. The TCP client keeps its event listeners across reconnects and ignores events from a client socket that has already been replaced. NATS and Kafka clients keep a newer connection when a stale one fails, instead of letting the old failure tear down the new link, and the NATS client can recover after it has given up reconnecting. With Redis wildcards enabled, replies now go out on the request channel.
Outside microservices, the release fixes logger bugs in JSON output, level changes, fatal and buffered logs, preserves string enum values that match numeric member names, and makes the core detect circular dependencies across more than two providers. The Fastify adapter now treats a JSON content type with parameters as JSON in reply(), class and factory overrides of value providers are honoured in testing, and ParseArrayPipe rejects non-numeric items when items are declared as numbers. Deserializers are now exported from the microservices package root.
What it means
Reconnect logic is the code that runs least often and fails worst, usually during an incident on the broker side. A patch that fixes it across five transports at once is worth taking promptly for any service that talks to a message broker through Nest's clients, and worth testing by actually restarting the broker in staging.