Current the only simple way to create a new msg clean object is to use a function node. Lots of users try to avoid using function nodes and want to achieve the same using a core node. The most obvious would be some option within the change node that allows for this.
Several thoughts have been mentioned so far.
add a clear object verb to the list
add "whole msg" to the delete typed-input list of options
somehow all user to create complete msg option (set msg)
Personally I think having option 3) set msg. and set msg options are too close and would be confusing (and then make the list next choice of type very "interesting" - ie if in msg mode it would then need to verify that an object was being created... all added complexity - and indeed the json/jsonata required to set it would be more easily entered in a function node.
I have often wanted to alter the root msg in a change node, If you are going to consider create blank/remove all properties, it would be nice to be able to set the root msg to.
eg.
set msg to JSONata expression for example. with some protection that it can only be an object (after thinking this may not be needed).
or
If you have the ability to set the msg, then set msg to {"flush":1} would delete and set your property in one go.
I prefer option 3, there is no check in the function node that it outputs an object, all you receive is a message in side panel that the msg is incorrect. So there would be no need to check in change node either
As you described the requirement, I instinctively went to what you have listed as option 2 - add "whole msg" to the delete typed-input list of options.
That helps you get rid of all unwanted properties without having to know what they are called. You then still have to add multiple set rules to add the individual properties you want. But if you wanted to keep any of the old message properties - bad luck, they have already been removed by this point. I imagine some users won't appreciate that and they will still fall back to the Function node for convenience. But it would at least make it possible to do and I'm sure some users would prefer this approach, rather than force the user to option 3...
A version of option 3 could be to add Complete message to the msg./flow./global. list of options - something that is clear and distinct to avoid confusion over the msg. option and the complete message option. If that option is selected, only allow msg/flow/global/JSON/JSONata in the list of 'to the value' types - ie the ones that are capable of generating a valid object. You are right it would still need runtime validation that the resulting message is a valid message.
An issue with this feature, which applies to the Function node as well but needs to be acknowledged, is what to do with the 'system' properties we have on messages. Such as _msgid, parts, _linkSource (adding by Link Call node). Removing those properties will break flows unexpectedly - so should they be considered 'protected' and only removed by the Change node if a Delete rule explicitly names them? In other words, if present, they are always restored onto any 'new' message the Change node generates, unless a Delete rule subsequently removes them.
I was trying to say that option 3 would give user the option to preserve them.
But option 1 and 2 would not unless there was a check boxes "preserve sytsem properties" or similar.
Iām not sure of a scenario where I would need to maintain _parts but remove (and then rebuild) all the other info. Modify yes. Or replace payload (the property that changes between different parts). But not all
Dave is referring to the .parts property I mentioned - used by the Split/Join nodes (and others) when creating a sequence of messages.
Okay.. but the point remains: there are 'system' properties on messages that user's might not be aware of but are critical to a flow's operation. Should they be preserved or not?
The Function node does restore the _msgid property if a new object is returned without it set. So at a minimum, the Change node would have to do the same.
Ok then we have more thinking to do. As this whole thread was kicked off by the need to send a msg with just msg.flush set to the delay node otherwise it sends/queues a āblankā msg
I don't follow. What has this got to do with the Delay node behaviour?
I understand the original requirement came from a desire to create a message with just flush set on it. So where does question about the Change node sending 'blank' messages come into play with that?
Currently if you want to flush a message from the delay node then you can either add msg.flush to an existing msg or just send msg.flush... If you do the first then the msg is sent through (so no "real" data is lost - the existing data goes through as part of the flush). If you do the second then it doesn't send on a message as that would be adding an extra (probably malformed) msg into the flow (as all the other properties would not be set for the downstream flow). - The requirement was how to create this msg.
It ignores _msgid already so if the clear/new message capability maintained _msgid for traceability that would be ok.
