Overriding node properties with message properties

[Nicholas O'Leary]

Some nodes allow their properties to be set by the properties of the received messages.

For example, you can set the filename the File node uses in the node itself, or override it with msg.filename.

This behaviour can have some unexpected, undesirable, side effects where a node has been explicitly configured to act on one filename, but then receives a message with filename set. If the user doesn't want the node's behaviour to be overridden by the message, they would have to ensures any received message doesn't have msg.filename set. This puts the burden on the user to know all of the properties that might get overridden in a node.

As such, we've decided the preferred behaviour is to only allow a msg property to override a node property if the node property has not been set (ie is blank).

We are deprecating the behaviour of using a message property when the corresponding node property has been set.

This preferred behaviour is already how some of the existing nodes do it - the MQTT nodes for example.

The core nodes that have the now-deprecated behaviour are:

  - File

  - HTTP Request

  - Email

We have updated those nodes so they will log a warning if they detect this behaviour being made use of. The deprecation warning includes a link to a page on the wiki that explains the background - http://bit.ly/nr-override-msg-props - to encourage users to update their flows to not depend on this.

The intention is this deprecation warning will remain in place for the next release. We will then update the nodes in the release after that to meet the preferred behaviour.

Any questions, comments or concerns - ask them here.

Nick

[Guilherme Ramos]

This is a bit of an old topic, but I've just noticed the deprecated message in one of my flows.

What I find strange is that it's being caused by 2 HTTP request nodes in sequence.

Here is the sequence of events...

HTTP GET Request -> Function to parse values -> HTTP POST Request.

I never change the msg.url property in my flow, but the second HTTP POST node complains about it since it was already set previously.

To get around this, I have to add a msg.url = null to my function.

It seems a bit awkward that it complains in the first place, since I'm not override the property myself.

[Dave C-J]

Hi,

Yes, that was a mistake that slipped into 0.10.4. The output was changed in advance of the deprecated behaviour being removed. It has since been backed out.

[The ThingBox]

"old topic" that I still do not understand.

Now, every field that can be set in msg should have (see screen dump):