Add possibility of catch errors when message broker is down

[vahidvdn]

Is there an existing issue that is already proposing this?

• [X] I have searched the existing issues

Is your feature request related to a problem? Please describe it

In express based applications, we can catch the broker error as following:

mqttClient.on('reconnect', () => {
    console.log('reconnecting...');
    // notify to sentry
})

While it seems this is not possible in NestJS.

Describe the solution you'd like

I tested the global filters but didn't work. Similar way or any other way could be very nice.

Teachability, documentation, adoption, migration strategy

No idea for now

What is the motivation / use case for changing the behavior?

As I mentioned, I need to send a message to Sentry and log in my system, whenever the broker is down.

[kamilmysliwiec]

So far the only way to accomplish this is to use a custom strategy that extends the built-in transporter. Example:

import { ServerMqtt } from '@nestjs/microservices';
import { MqttClient } from '@nestjs/microservices/external/mqtt-client.interface';

class MyCustomStrategy extends ServerMqtt {
  bindEvents(mqttClient: MqttClient) {
    super.bindEvents(mqttClient);
    mqttClient.on('reconnect', () => console.log('Reconnecting...'));
  }
}

// and later
const app = await NestFactory.createMicroservice<MicroserviceOptions>(AppModule, {
  strategy: new MyCustomStrategy({
    url: 'mqtt://0.0.0.0:1883',
  }),
});

[vahidvdn]

Thanks, @kamilmysliwiec I found something regarding bindEvents in the source code of nest, but was not sure how to use it.

But it would be great if it were mentioned in the docs.

[micalevisk]

@vahidvdn feel free to propose an improvement to the docs here: https://github.com/nestjs/docs.nestjs.com via pull request

[vahidvdn]

@micalevisk I will do it asap. I have a section in my mind in the overview menu right after handling timeouts (maybe called handling events) and refer to Custom transporters menu for more info. Does that work for you?

[kamilmysliwiec]

Instead of creating a new page, we should add a dedicated section to each transporter as the implementation can vary considerably

[vahidvdn]

@kamilmysliwiec That makes perfect sense to me. But it would be great if you could mention the overall solution in the overview menu regarding bindEvents. Then based on the underlying package used (e.g. mqtt.js), developers can either go to the dedicated menu for that specific transporter or use the mqtt documents (or their knowledge about that) to see which events is present.

By the way, it was just an idea. I will try to add them to the mqtt secotion at least, and adding some overall information to the overview menu is your call. Thanks