Why delete message properties?

What are some general examples or reasons to delete a message property?

https://cookbook.nodered.org/basic/delete-message-property

Maybe one instance is when a payload is split up, following different branches...

Maybe you need to save msg.payload before using a node that over writes msg.payload and then you need to move the data back to msg.payload for some other reason, so you do some clean up.

There are a number of reasons why you may want to delete a message property:

  1. If you have a flow that branches, each branch will get a clone of the message. If you have a message property containing a very large object that you don't need anymore, it would be much more efficient to delete that property before the flow branches.

  2. There are some commonly used message properties that affect the behaviour of nodes. For example, msg.topic, msg.reset and others. You may need to delete that property after passing it to Node A to stop it affecting Node B later on in the flow.

  3. Similar to #2, some of the network I/O nodes (TCP, UDP, WebSocket) set a property called msg._session that identifies the source of a message. If you pass a message with that msg._session property set to a corresponding Output node, the node will send the message back to the original sender. However, you may want to broadcast out to all connected clients, so you'd delete msg._session.

  4. Some storage nodes have an option to store the complete message object - some of the Mongo nodes for example, So you may want to delete properties on the message you don't want storing in the database.

I'm sure there will be plenty of other reasons why you may need to delete a message property.

1 Like

Can I just ask then:

I send a message into a node - say: trigger.
It has msg.reset to true.
That message stops at the trigger node - doesn't it?
Or do you mean that because I usually have that constructed else where and therefore no other stuff I don't see the message coming out because there is nothing left to send?

To expand on that slightly:
So if I sent out of what ever node: {msg.payload:"foo",msg.reset:true}
into the trigger node I would get foo out of the trigger node?

To further confuse the issue, I tried that and it doesn't work as I just explained.

(code)

[{"id":"2cef468.1f5173a","type":"trigger","z":"5b6dee10.d1621","name":"","op1":"1","op2":"0","op1type":"str","op2type":"str","duration":"50","extend":false,"overrideDelay":false,"units":"s","reset":"","bytopic":"all","topic":"topic","outputs":1,"x":830,"y":1650,"wires":[["2bdef8e7.a379e8"]]},{"id":"2bdef8e7.a379e8","type":"debug","z":"5b6dee10.d1621","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":1060,"y":1650,"wires":[]},{"id":"1d7ffa5b.22f4d6","type":"inject","z":"5b6dee10.d1621","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":660,"y":1580,"wires":[["2cef468.1f5173a"]]},{"id":"73eaea20.b2e5d4","type":"inject","z":"5b6dee10.d1621","name":"","props":[{"p":"payload"},{"p":"reset","v":"true","vt":"bool"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"foo","payloadType":"str","x":660,"y":1650,"wires":[["2cef468.1f5173a"]]}]

Thanks.

I think you are over thinking msg.reset in relation to the trigger node. Stated is " If the node receives a message with a reset property, or a payload that matches that configured in the node, any timeout or repeat currently in progress will be cleared and no message triggered."

The last three words are the key.

@knolleary stated " You may need to delete that property ...". In the case of the trigger node, passing in msg.reset deletes the whole msg, there is nothing left to delete.

Your example demonstrates this I think?

Yeah, I seem to live at the two extremes.

Either not thinking about it or over thinking it. :face_with_raised_eyebrow:

1 Like

Another use case: I often delete the msg.topic after database nodes. Since some queries can be quite long, it makes using the debug panel harder to read if the topic is too long.

1 Like