fix(microservices): adds feedback message when RabbitMQ server connection hangs

[delucca]

PR Checklist

Please check if your PR fulfills the following requirements:

• 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

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

What is the current behavior?

Issue Number: #9749

If a RabbitMQ connection fails, NestJS keeps trying to reconnect but no log message is dispatched. So, the user thinks the server frozen and it is not doing anything else.

What is the new behavior?

Upon a failed connection on the RabbitMQ server, I've added an error log to show what happened to the user.

Does this PR introduce a breaking change?

• Yes
• No

Other information

At first we were considering that #9726 was also impacted by this issue, but it isn't, since this is specific to how RabbitMQ handles failed connection attempts.

[coveralls]

Pull Request Test Coverage Report for Build fe9290e2-9103-4c52-a729-c9dcd92384d8

• 2 of 4 (50.0%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.03%) to 94.078%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
packages/microservices/server/server-rmq.ts	1	3	33.33%

Totals
Change from base Build 3833bc5d-ac71-4db9-b614-33791ff96fb8:	-0.03%
Covered Lines:	5783
Relevant Lines:	6147

---

💛 - Coveralls

[micalevisk]

I wonder if wouldn't be better (more flexible) if we just expose the underlying server by returning this.server in ServerRMQ#start 🤔

[delucca]

I wonder if wouldn't be better (more flexible) if we just expose the underlying server by returning this.server in ServerRMQ#start 🤔

I'm not sure if that would solve the issue. Do you know if by returning it we would prevent the server retrying to start?

Because the current issue is that we're stuck in a loop were the server keeps trying to connection and the event we receive from the RabbitMQ client is not being handled by our server, so we don't get any log message in the terminal

[micalevisk]

Do you know if by returning it we would prevent the server retrying to start?

it still won't.

I'm unsure if there is any other way to listen to that connectFailed event. So what if we want to handle it instead of just logging it out? By returning the server we could handle that in our preferable way

[delucca]

Do you know if by returning it we would prevent the server retrying to start?

it still won't.

I'm unsure if there is any other way to listen to that connectFailed event. So what if we want to handle it instead of just logging it out? By returning the server we could handle that in our preferable way

I ran a few quick tests here, it seems the RabbitMQ client has this built-in feature of retrying the connection if it fails.

What do you think should be the optimal approach from NestJS perspective (ignoring RabbitMQ client)?

• Upon a failed connection, we should log and error and continue with the application bootstrap, without retrying?
• Upon a failed connection, we should log and error, continue to bootstrap the application and retry the connection on the background?
• Upon a failed connection, we should log the error, retry N times and them end the process afterwards if the connection fails on all attempts?

I think how we handle this depends on that decision 🤔

[kamilmysliwiec]

@delucca what you did here in this PR is correct and aligns with other transporters. Thank you!

[avec-as]

Hello,
good to have more log, but not a good idea I think to directly log the error because it's log the entire connection object with the password in plain text !!!