JOIN Node - Disappearing property

Hello there, using the JOIN Node, one of the property disappears after it.

JOIN configuration: Mode manual, Combine each msg.payload to create a merged object after a number of message parts: 4.

Here is a reproduction of my flow (without sensible data):

payload pics

msg = {
    payload: {
        pictures: [ ... ]

payload data

msg = {
    payload : {
        correlationId: "idididid",
        timestamp: "2020-02-10T09:52:51.324Z",
        expectedData: { ... }


The property msg.payload.correlationId is in input of the JOIN Node and missing after. Weird thing is it's only occurring in my "production" flow (with real trigger and much more actions), not using a flow like above.

I've bypassed this by renaming the property before the JOIN and renaming it back after.
Any reason why this particular name would trigger such behavior? I've not found any variable with that name anywhere.

Could you share the flow json so we can more easily try to recreate it?

This is the reproduced flows [{"id":"2ac58527.f84daa","type":"tab","label":"Generic","disabled":false,"info":""},{"id":"5a28274f.6cc748","type":"function","z":"2ac58527.f84daa","name":"data","func":"msg = {\n payload : {\n correlationId: \"idididid\",\n timestamp: \"2020-02-10T09:52:51.324Z\",\n expectedData: {}\n }\n};\n\nreturn msg;","outputs":1,"noerr":0,"x":290,"y":120,"wires":[["40a7d30a.b49dbc","ec492e65.4b03f"]]},{"id":"9e753480.d18ec8","type":"inject","z":"2ac58527.f84daa","name":"","topic":"","payload":"","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":150,"y":120,"wires":[["5a28274f.6cc748"]]},{"id":"40a7d30a.b49dbc","type":"debug","z":"2ac58527.f84daa","name":"data","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","x":430,"y":140,"wires":[]},{"id":"ec492e65.4b03f","type":"join","z":"2ac58527.f84daa","name":"","mode":"custom","build":"merged","property":"payload","propertyType":"msg","key":"topic","joiner":"\\n","joinerType":"str","accumulate":false,"timeout":"","count":"4","reduceRight":false,"reduceExp":"","reduceInit":"","reduceInitType":"","reduceFixup":"","x":430,"y":100,"wires":[["e7998297.06b9e"]]},{"id":"e7998297.06b9e","type":"debug","z":"2ac58527.f84daa","name":"join","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","x":570,"y":100,"wires":[]},{"id":"6f2c5eca.8ac37","type":"inject","z":"2ac58527.f84daa","name":"","topic":"","payload":"","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":150,"y":80,"wires":[["87ca0a1f.7759f8"]]},{"id":"87ca0a1f.7759f8","type":"function","z":"2ac58527.f84daa","name":"pics","func":"msg = {\n payload: {\n pictures: []\n }\n};\n\nreturn msg;","outputs":1,"noerr":0,"x":290,"y":80,"wires":[["ec492e65.4b03f","42c46555.01c73c"]]},{"id":"42c46555.01c73c","type":"debug","z":"2ac58527.f84daa","name":"pics","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","x":430,"y":60,"wires":[]}]

The msg.payload.correlationId show up for me
Screen Shot 2020-02-10 at 2.45.26 PM

I believe without the proper parts metadata, the join node will wait for any 4 parts and continue with those.

So, if in production many more messages arrive in an undetermined order, is it possible you received at least 4 pics in a row and the data later on? That would be one explanation for the missing data from the other input.

You might be better using key/value pairs mode (make sure the two message paths have different topics). Then you might also want And After Every Subsequent Message.

@zenofmud Yes it is showing with this flow. I don't know why it is disappearing in my real flow (which I cannot send as it contains real data and rely on hardware setup.

@kuema Yes, the JOIN node will be triggered every 4 parts, whatever they are coming from.
I can receive a variable number of pictures as I have a JOIN node before to concatenate all data into one payload containing one array "pictures".
The flow behaves normally, getting all parts needed in the right order. By the way it's setup, it's not possible for a payload to be sent twice before the other one.

@Colin "Every subsequent message" means the JOIN will be trigger after 4 parts and then every part received. This is not what I need.
The "key/value" mode would require to change the way I use the payload after. For now, my workaround is sufficient but I'm looking for an explanation of the bug :slight_smile:

Since the 'demo' flow you provided works, and you can't provide your real flow, there is not much anyone can do to help. You could put a delay node (set to 1 second) before the join and attach a debug to both the output of the delay node and the output of the join, so you will have arecord of the msg's entering the join and the joined message. That may help you to determine what is happening.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.