[RabbitMQ node] arguments are not added to the message

[dokime7]

Describe the bug Unable to add arguments on RabbitMQ node The arguments are not added to the RabbitMQ message properties (show by RabbitMQ management webui).

To Reproduce Steps to reproduce the behavior:

1. Add a RabbitMQ node
2. Add some arguments key / value like: content_type: application/json
3. Send the message on an exchange topic with a routing key
4. Get the message from the queue on RabbitMQ management webui
5. Nothing on properties

Expected behavior The arguments set on the node is well added to the RabbitMQ message.

Environment (please complete the following information):

• OS: Ubuntu 20.04.3
• n8n Version 0.162.0
• Docker image n8nio/n8n:latest DIGEST:sha256:928374e08715767e4c4905050b6d10f1498e0ba43cc91d5ad004b5f366ec60d6
• Database system SQLite
• Operation mode queue

Additional context I would like to add content_type: application/json and content_encoding: utf-8 to RabbitMQ message properties because some consumers can't read the message payload without to know to content_type.

[rishi003]

I checked the node that is executing Rabbit MQ and arguments are being passed in the options.

[dokime7]

Hmmm.... I will check again with the lastest version of RabbitMQ.

[dokime7]

I can confirm with the last RabbitMQ 3.9.14 and lastest n8n version that no Arguments are received by RabbitMQ. Headers are received but no Arguments (called properties on RabbitMQ).

[netroy]

@dokime7 do you want the Queue arguments to also show up as properties on every message? From what I understand that's not a very common behavior, and definitely does not happen automatically.

perhaps there needs to be an additional section to add properties in the RabbitMQ node, which get added to very message that gets published by this node.

Regarding content_type and content_encoding: If you add those as Headers insteadArguments in the node configuration, every message with have those values set in the headers.

Here is the output from a test subscriber:

[dokime7]

Hi, I thought that arguments in n8n are properties but not. What I need is to set contentType and contentEncoding values on properties (not on headers) because some consuming libraries use these values to determine the type of content.

[netroy]

@dokime7 what library are you using?

[dokime7]

https://nameko.readthedocs.io/en/stable/built_in_extensions.html#events-pub-sub

[dokime7]

So, it will be very useful to be able to add properties via a new section in n8n 🚀

[dokime7]

Hi here, what's news?

[Joffcom]

Just want to add that this should be fixed by #3244, Internally we are tracking this as NODE-113

[defunky]

Just want to add that this should be fixed by #3244, Internally we are tracking this as NODE-113

I'm using 1.16.0 I I cannot see a way to directly set properties on the RabbitMQ nodes? am I missing something. Much like the content-type we also use type property to correctly consume the messages, passing it via the header does not work for us either.

[Joffcom]

Hey @defunky,

You can set the property / arguments under the options when sending a message.

I have just taken a quick look and the change we did didn't seem to change these values not actually being sent, I have created a new ticket to tackle this which we are tracking as NODE-1031.

[technohood]

Any update on this guys?

I tried many times to use the "durable" option when sending a message but it is not being sent, Nor any arguments. I tried with latest n8n version, even n8n cloud. same thing. Beside the fact that non of the arguments are set to RabbitMQ, Any message that you send to RabbitMQ won't survive any restart to the RabbitMQ service. same reason as the "delivery_mode" is an argument for the message.

Am I missing something???

[rootindex]

There seems to be a disconnect here, the channel gets the properties, but I want to add custom properties to a message not a channel, this does not seem to occur at the moment.

Channel gets option.properties

Similar to how the header gets set, we should be able to set custom arguments to the message being send itself.

options.headers exists but we we want to send options.{customProperty} not just the headers.

Additional note: be sure to use camel case and not snake case when using the messages custom properties, that seems to be an amqplib requirement.