Rabbit MQ triggers do not work in test mode

[DRIMOL]

Bug Description

A - Does not pull the item from the queue in test mode

B - If you write a message to a queue that does not exist, it returns an error. ERROR: Operation failed: QueueDeclare; 404 (NOT-FOUND) with message "NOT_FOUND - no queue 'test_queue' in vhost 'default'

To Reproduce

A1 - adicione uma nova mensagem no rabbit mq A2 - coloque o triggers em modo de escuta

A PS: No painel do rabbit MQ a messagem entra em Unacked, mas, no workflow do n8n nada acontece

B1 - try to write a message to a queue that doesn't exist

Expected behavior

A - Test message reception by rabbit MQ

B - Create new queues through the RabbitMQ node

Operating System

UbuntoLinux 20

n8n Version

1.31.2

Node.js Version

v18.19.1

Database

PostgreSQL

Execution mode

queue

[Joffcom]

Hey @DRIMOL,

Thanks for reporting this, I have created NODE-1230 as the ticket to fix the bug, With the second one I would expect it to fail if the queue doesn't exist as we don't set the option to create it.

If you want us to add this I would recommend creating a feature request on the community support forum and we can track the popularity of this and look at adding it in the future.

[DRIMOL]

I thought it was a BUG, ​​because in version 1.24.1 it creates the queue if it doesn't exist.

Thanks

[Joffcom]

Hey @DRIMOL,

That was some important information that was missing... Looking at the release this was changed in 1.28.0 with this PR: https://github.com/n8n-io/n8n/pull/8430 and it looks like I missed that the change was not added to the standard node.

I will get that fixed shortly for the next release.

[DRIMOL]

Where can I track the progress?

[Joffcom]

Hey @DRIMOL,

This is the best place to check, Once fixed we will put a note on here to let you know. You can also keep an eye on the PR list to see if any of them contain node-1230.

Right now this is sat with a high priority and is waiting to be picked up.

[barn4k]

Actually, better to have an option like "Create if no queue" to avoid misconfigurations.

But I can imagine only one scenario when it might be needed - If someone by mistake has deleted a queue

[barn4k]

Hey @Joffcom , bug with the 404 instead of creating a queue is still there...

[Joffcom]

I have created a PR to fix the queue creation, Oddly enough when testing I noticed that running in test mode is working as well. @DRIMOL / @barn4k are you able to check on 1.41.0 to see if the test execution is working for an existing queue?

[Joffcom]

Thanks to a quick review from @netroy it looks like the option to make the queue is there already under Add Option > Assert Queue. This should resolve the issue of the queue not being created automatically.

[barn4k]

I have created a PR to fix the queue creation, Oddly enough when testing I noticed that running in test mode is working as well. @DRIMOL / @barn4k are you able to check on 1.41.0 to see if the test execution is working for an existing queue?

Well, I can't check it right now as the latest docker version is 1.39.1 :)

[Joffcom]

@barn4k latest should be 1.41.0 now 😄

[barn4k]

@Joffcom Just tested on 1.41.1, Test Workflow/Test Step still don't work. It keeps loading forever

And I see that the node tried to consume the message but it stucked there (Unacked state)

Even after I have stopped the execution, it still holds the message

I've tried both: using the current RabbitMQ node and creating a totally new one

[DRIMOL]

I have created a PR to fix the queue creation, Oddly enough when testing I noticed that running in test mode is working as well. @DRIMOL / @barn4k are you able to check on 1.41.0 to see if the test execution is working for an existing queue?

Well, I can't check it right now as the latest docker version is 1.39.1 :)

here it is also loading infinite na versão 1.41.0

[DRIMOL]

Thanks to a quick review from @netroy it looks like the option to make the queue is there already under Add Option > Assert Queue. This should resolve the issue of the queue not being created automatically.

yes, it already exists in the trigger, but the interesting thing would be if it was in the "Send a Message to RabbitMQ", because then we would be able to create queues dynamically.

[DRIMOL]

Será que ainda vão resolver ? 😞

[luizeof]

@Joffcom Setting Up N8N_LOG_LEVEL=verbose I can see the error that happens when the rabbit trigger is started:

2024-06-06T22:56:04.076Z | error    | There was a problem with the RabbitMQ Trigger node "RabbitMQ Trigger" in workflow "hAKRgkvpANXAoSTW": "Overwrite NodeExecuteFunctions.getExecuteTriggerFunctions.emit function" "{\n  node: 'RabbitMQ Trigger',\n  workflowId: 'hAKRgkvpANXAoSTW',\n  file: 'LoggerProxy.js',\n  function: 'exports.error'\n}"

[ramonmatosweb]

n8n20ylvns_n8n20ylvns_logs.txt

[Joffcom]

This will be fixed very soon.

[DRIMOL]

This will be fixed very soon.

I would like to add a bug that I noticed these days also about the rabbit

If I inactivate or delete an n8n flow where there is a rabbit trigger, the consumer is not automatically deleted from the rabbit, and continues to be sent to a ghost consumer, even though it has been deleted, the problem is only solved by updating n8n with prune , by doing this he excludes ghost consumers.

[netroy]

If I inactivate or delete an n8n flow where there is a rabbit trigger, the consumer is not automatically deleted

When you deactivate the workflow, do you see any error in the container logs saying something like There was a problem closing the RabbitMQ Trigger node connection?

[DRIMOL]

If I inactivate or delete an n8n flow where there is a rabbit trigger, the consumer is not automatically deleted

When you deactivate the workflow, do you see any error in the container logs saying something like There was a problem closing the RabbitMQ Trigger node connection?

I will try to check if I should look at this log in the n8n workers or in the RabbitMQ container?

[netroy]

I will try to check if I should look at this log in the n8n workers or in the RabbitMQ container?

Please check in the n8n worker logs.

[DRIMOL]

I tried to catch the bug here, but it excluded the consumer, it could have happened because the queue had a stuck message, for example when "parse json" is marked and the message arrives outside of the json format, in this case or something similar does not exclude, but by deleting a trigger that is "healthy" here the consumers were excluded from the rabbit