RabbitMQ trigger doesn't reconnect

[Ken-Michalak]

Describe the bug
If a workflow with a RabbitMQ trigger is active and the connection to it is interrupted, the workflow will stop receiving messages until it is turned off and back on.

To Reproduce
Steps to reproduce the behavior:

1. Create a workflow with a RabbitMQ trigger.
2. Activate the workflow.
3. Restart the RabbitMQ server.
4. Wait for RabbitMQ to come back online.
5. Check the number of consumers for that queue in the RabbitMQ cli or management webapp, which will be 0. Or send a message into the queue, which will not get picked up by the workflow.

Expected behavior
I would expect the workflow to attempt to reconnect on some interval, and possibly display an error in the UX when the workflow is not running. Once the server or network issues are resolved, n8n should reconnect, RabbitMQ should show 1 or more consumers, and the workflow should begin consuming messages again.

Environment (please complete the following information):

• OS: Ubuntu Linux 20.04.2 (K8s with node:14 image)
• n8n Version: 0.129.0
• Node.js Version: 14.17.3
• Database system: MariaDB 10.5
• Operation mode: queue

Additional context
I also attempted to use the AMQP 1.0 trigger, since we have that plugin enabled in RabbitMQ, but a disconnect or misconfigured trigger on there causes the main process to crash.

[lcx]

Posted about this here: https://community.n8n.io/t/no-reconnect-if-rabbitmq-server-restarts/5572
Should have created an issue.
The current situation is that restarting n8n will then start workflows for all messages at once. My machine currently has a load of load average: 136.79 :(
Keep forgetting to restart n8n when I restart rabbitMQ

[janober]

Got fixed and will be released with the next version.

[jspizziri]

@Ken-Michalak please review the referenced PR to verify it was properly fixed.

[Ken-Michalak]

@jspizziri From the pr, it looks like it might, but I haven't had a chance to verify it yet.

It wouldn't fix the issue that @lcx mentioned though. There needs to be a prefetch or at least a way to configure one to prevent that. Without it, the consumers try to get all of the messages in the queues at once when it reconnects. If the disconnect is on the n8n side, while rabbitmq is still getting messages from elsewhere, then it could still get overloaded. I'm not sure if there should be a separate issue for that, but it would get fixed with #3244

[janober]

Fix got released with n8n@0.196.0

[janober]

The current node has already a setting for a while, to define how many messages should be processed at once. So also that problem got already fixed.