Currently the Join node will use the last message to arrive a the “template” for the outgoing message. The payload contains the joined up parts of the message. What this means is that any properties above payload (i.e. directly on msg.) will ONLY come from the last message to arrive. If the user adds any other top level properties on any but the last message to arrive they will be lost.
As this is the join node after all - it would probably make sense to also merge as many top level properties as well - with newer arrivals overwriting any older ones. The net result would be that the outgoing msg would still contain the last properties to arrive - but would also include any other top level properties from other parts. (i.e. a superset).
Question : should this be the default behaviour ? (or indeed the only behaviour). Or should it be an option that has to be selected ?
I would like to make it the default/only behaviour - BUT this is a change that could cause breakage if someone is relying on other properties NOT to be there… so a bit niche… but…
The proposal would not cause me any problems, but while you are in there would you consider adding a new option to the msg.complete operation called something like Retain Last Values? If that option is set then when msg.complete is received then the current data will be sent, but the saved data will not be cleared, so that if another complete is received then the latest data will be sent again. This would provide for a not uncommon requirement of saving the latest values of stuff and sending it at regular intervals or on some trigger event.
Which should do what you are suggesting... I think... ie just adds/replaces properties in the existing object.
I don't think this option makes sense for joining strings or arrays or they would never get reset to zero size and would just keep expanding as there is no concept of replace for these.
That doesn’t do quite the same thing. I only want it to send on msg.complete, not on all the intermediate messages. Currently I do this by configuring it as you show and sending a message with topic set to “complete” when I want the message, and using a switch node to ignore the intermediate messages. My suggestion would mean I could remove that node.
I don’t know the case where this proposal cause problems.
My question is whether is appropriate to always use the value of the last message for outgoing message. In cases similar to the original problem, it may be good to use logical and/or for set of values. However, this should be an extension of Reduce Sequence mode.
Thank you. Indeed the last message was just the way it was/is coded as the msg had to come from somewhere and picking the last meant nothing needed to be stored… as the payload is the real property of interest… apart from when it isn’t the only property of interest of course - so I think it’s somewhere between a bug and poor decision.Question is - does fixing/improving it break anyone ?
Yes I agree - for more logical selection of parts then the reduce sequence with it’s jsonata support makes more sense.
