Steveorevo/node-red-emerge

No merge or helpful error given when msg.payloads are different types

Closed this issue · 2 comments

Hey, I've spotted that when the msg.payload of inputs are a different type (e.g. input 1 payload is json, input 2 payload is string) then no merge happens and no helpful error message is shown (even in the catch). The catch just appears to show the last message that was sent to emerge.

I assume the same behaviour would be seen for any given key if the type was different...

I've attached an example below :)

[{"id":"0a5d142fe493b32a","type":"emerge","z":"c4b3f62035982a12","name":"wait for all user info","grpRules":[{"ruleProperty":"payload.first","rulePropertyType":"msg","ruleOperation":"!empty","ruleValue":"","ruleValueType":"str"},{"ruleProperty":"last_name","rulePropertyType":"msg","ruleOperation":"!empty","ruleValue":"","ruleValueType":"str"},{"ruleProperty":"occupation","rulePropertyType":"msg","ruleOperation":"!empty","ruleValue":"","ruleValueType":"str"}],"ruleProperty":"payload","rulePropertyType":"msg","ruleOperation":"==","ruleValue":"","ruleValueType":"str","rulesTimeout":"10","timeoutAction":"2","x":310,"y":100,"wires":[["4c5d7bca520c0054"]]},{"id":"621efb1c34f39daa","type":"inject","z":"c4b3f62035982a12","name":"first_name","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"{\"first\": \"Zack\", \"boop\": \"loop\"}","payloadType":"json","x":100,"y":40,"wires":[["0a5d142fe493b32a"]]},{"id":"cb8c62f1de3d970e","type":"inject","z":"c4b3f62035982a12","name":"last_name","props":[{"p":"last_name","v":"Burton","vt":"str"},{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"hi","payloadType":"str","x":100,"y":100,"wires":[["0a5d142fe493b32a"]]},{"id":"5683ab4dc09a100f","type":"inject","z":"c4b3f62035982a12","name":"occupation","props":[{"p":"occupation","v":"truck driver","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":100,"y":160,"wires":[["0a5d142fe493b32a"]]},{"id":"4c5d7bca520c0054","type":"debug","z":"c4b3f62035982a12","name":"debug 1","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":500,"y":100,"wires":[]},{"id":"07d39fc7521c77a2","type":"catch","z":"c4b3f62035982a12","name":"","scope":["0a5d142fe493b32a"],"uncaught":false,"x":450,"y":140,"wires":[["6adcb8dce8d765c7"]]},{"id":"6adcb8dce8d765c7","type":"debug","z":"c4b3f62035982a12","name":"debug 19","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"error.message","targetType":"msg","statusVal":"","statusType":"auto","x":660,"y":180,"wires":[]}]

Thanks Tom for the flow to easily reproduce the issue. I've corrected for it where by if the incoming property and existing properties are not both objects; the value will get updated (stomped on by the incoming message). I.e. this should correctly cast payload to the incoming object, even if its prior value was string.

With regards to the error message, it looks like I mis-read the way catch node works as I can only pass back a string message. In theory I could serialize the msg buffer to the error message; but I'm not sure how clean that would look or if catch node could handle large serialized objects. The leftover content of the msg object is the last incoming message that I unfortunately do not have reference access to update with the internal msg buffer.

I'll publish the other fixes here shortly in v1.3.0

Version 1.3 has been pushed to npm and updated on https://flows.nodered.org/node/@steveorevo/node-red-emerge. It should appear in the palette manager soon. Will close this item; please request re-open or feel free to file new issue number for any other issues.