Switch node using any JSONata expression ceases to pass messages when msg.parts is set

General
1

So strange... Switch nodes taking advantage of JSONata as a criterion for any output seem to cease passing on ALL messages on ALL outputs should msg.parts get set. This is happening irrespective of the nature of any of the comparisons-- even the tautologic msg.payload == msg.payload is failing.

Similarly, outputs gated as "otherwise" are silent, even when none of the other outputs pass a message. Nor does the problem seem to be related to JSONata specifics as any valid expression seems to be enough to trigger the problem.

There are no error messages, nor have I been able to see anything amiss in the logs, even turned up to "trace".

Specifically, the node only seems to fail if both msg.parts.id and msg.parts.index are set. Their values don't seem to matter. Slightly tweaking the either of the names of the properties (msg.parts.idx for example) causes the effect to disappear. The rest of the typical content of msg.parts does not seem to have any effect.

Please help? I cannot figure this one out... If anyone can spot what I'm doing wrong or what is going on, I'd be extremely grateful!! Or, if anyone can verify this behavior I would also very much appreciate it.

Thank you in advance!

Example flow:

[{"id":"5d0cb663.4aa908","type":"switch","z":"a7574de8.bfab9","name":"","property":"payload","propertyType":"msg","rules":[{"t":"eq","v":"payload","vt":"msg"},{"t":"jsonata_exp","v":"true","vt":"jsonata"},{"t":"else"}],"checkall":"true","repair":false,"outputs":3,"x":710,"y":320,"wires":[["eb1805b1.965398"],["bf6110fe.2370d"],["3f0c7057.aec39"]]},{"id":"6ed41ff2.3317c","type":"inject","z":"a7574de8.bfab9","name":"","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":220,"y":220,"wires":[["1aa17f3f.bfadc1"]]},{"id":"eb1805b1.965398","type":"debug","z":"a7574de8.bfab9","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","x":870,"y":280,"wires":[]},{"id":"1aa17f3f.bfadc1","type":"change","z":"a7574de8.bfab9","name":"FAILS: msg.parts.id & msg.parts.index set","rules":[{"t":"set","p":"parts","pt":"msg","to":"{\"id\":\"a\", \"index\":1}","tot":"json"}],"action":"","property":"","from":"","to":"","reg":false,"x":460,"y":220,"wires":[["5d0cb663.4aa908"]]},{"id":"bf6110fe.2370d","type":"debug","z":"a7574de8.bfab9","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","x":870,"y":320,"wires":[]},{"id":"3f0c7057.aec39","type":"debug","z":"a7574de8.bfab9","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","x":870,"y":360,"wires":[]},{"id":"c96495d4.7fe748","type":"inject","z":"a7574de8.bfab9","name":"","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":220,"y":280,"wires":[["c57441d5.732aa"]]},{"id":"c57441d5.732aa","type":"change","z":"a7574de8.bfab9","name":"works: msg.partz","rules":[{"t":"set","p":"partz","pt":"msg","to":"{\"id\":\"a\", \"index\":1}","tot":"json"}],"action":"","property":"","from":"","to":"","reg":false,"x":390,"y":280,"wires":[["5d0cb663.4aa908"]]},{"id":"44d93e92.4f001","type":"inject","z":"a7574de8.bfab9","name":"","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":220,"y":340,"wires":[["26b55b4f.0a1434"]]},{"id":"26b55b4f.0a1434","type":"change","z":"a7574de8.bfab9","name":"works: msg.parts.idd","rules":[{"t":"set","p":"parts","pt":"msg","to":"{\"idd\":\"a\", \"index\":1}","tot":"json"}],"action":"","property":"","from":"","to":"","reg":false,"x":400,"y":340,"wires":[["5d0cb663.4aa908"]]},{"id":"6e08752d.de033c","type":"inject","z":"a7574de8.bfab9","name":"","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":220,"y":400,"wires":[["cec94657.3987c8"]]},{"id":"cec94657.3987c8","type":"change","z":"a7574de8.bfab9","name":"works: msg.parts.indexx","rules":[{"t":"set","p":"parts","pt":"msg","to":"{\"id\":\"a\", \"indexx\":1}","tot":"json"}],"action":"","property":"","from":"","to":"","reg":false,"x":410,"y":400,"wires":[["5d0cb663.4aa908"]]}]
2

Which version of node-red and nodejs are you using? For the nodejs version run
node -v
The node-red version is shown at the bottom of the hamburger menu dropdown.

3

You are right, there is an issue. It is to do with the Recreate Message Sequences feature. If you select that, deploy, deselect it and deploy again then the problem is fixed.
It seems to think the checkbox is selected when it isn't.

4

Yes, this is a bug.

When the JSONata option was first added to the node, it was part of the message sequence rules added. Some of those rules require the message to be part of a valid sequence that includes msg.parts.count. For some reason, the JSONata type has been included in the list that requires msg.parts.count to exist. I can't see any reason for that given the expression runs on individual messages and not sequences.

Will fix for 1.1.0

1 Like
5

Does that explain why selecting the sequences checkbox, deploying, clearing it again, and deploying fixes it?

6

I cannot reproduce that bit of it. After clearing it and deploying, I still see the issue happen.

In the code, as far as the bug is concerned, the state of that checkbox is irrelevant if the rule is a JSONata expression type

7

Node-Red v1.0.6
Node.js v12.16.3

@Colin Thank you for the feedback! Unfortunately, checking the re-create box, deploying, clearing and deploying didn't actually change the symptoms for me. That leaves me a little concerned that maybe I'm seeing a related, but different issue... But at the same time, you sound familiar enough with the problem that it seems far more likely that it is indeed the same flaw and the difference in our experiences is due to other factors that are keeping it active in my environment. Happily, the issue is very focused and easy to work around so I'll keep my fingers crossed that the update planned in 1.1.0 will nail it.

@knolleary Thank you for the confirmation and update. One item to which I wanted to draw your attention: you mentioned that it appears the issue may be tied to msg.parts.count. I just wanted to make sure you are aware that in all my experimentation the problem behavior has presented entirely independent of msg.parts.count and has, instead, proven to be very closely tied to both msg.parts.id and msg.parts.index. Removing either of these properties alleviates the issue. Perhaps .id and .index are indirectly tied to .count, or maybe there is some other type of driving relationship...? In any case, I just wanted to bring that point to your attention on the off chance it is helpful or illuminates some other aspect of the bug. Thanks again and please let me know if there is anything I can do to help with the resolution.

Thank you both once again!

8

The node recognises the message as being part of a sequence if it has parts.id and parts.index set. At that point, if it was a JSONata expression rule, it (was) also requiring parts.count to exist.

9

No, neither can I. Time to submit an issue against my brain's s/w repo I think. Sadly it appears to be rather old and running on obsolete hardware with very limited support so I don't hold out much hope for the underlying issues getting fixed. :frowning:

2 Likes
10

Would that not suggest that adding a parts.count property to a malfunctioning scenario should restore utility? Unfortunately, that doesn't seem to be the case.

And, much more importantly, if the problem was due to a message with parts.id and parts.index identifying the message as part of a sequence, only to cause the node to puke when parts.count couldn't be found, then I should never have encountered the issue in the first place. The problematic messages are definitely members of a sequence. But as such, msg.parts has .id, .type, .count, .len and .index properties and therefore shouldn't ruffle any feathers if the problem is due to (inappropriately) looking for a msg.parts.count property that doesn't exist...

I'm highly confident that the presence of msg.parts.id and msg.parts.index are, just as you said, flagging the message as the member of a sequence. I'm just not seeing the role that msg.parts.count is playing in the problem.

If you're confident you've got a handle on this, please don't feel you need to spend your time cultivating the relevant concepts in my flimsy mental topsoil. I'm only still poking at this sucker in case I can help identify anything that might clarify the root cause and thus save effort spent chasing down unproductive lines.

11

Because it thought the rule was going to be applied across the whole stream, the node would have been queuing up the messages until the complete sequence had arrived. So simply adding a count property wouldn't necessarily have fixed it as far as handling individual properties go.

If you change the test case you provided to {"id":"a", "index":1,"count":1} you'll see it does pass through as expected. But for other values of count, I'm less certain what the resulting behaviour would be and I'm not delving into that hole right now.

Suffice to say, the fix I've done (to applied the JSONata expr to individual messages) addresses the whole question.

12

Excellent! Thank you so much for the explanation. That makes complete sense. It also explains how/why the node "fails" without making a peep as it is quietly accruing messages.

On a similar note, please accept a broader thank you for your ongoing efforts. They are very much appreciated.

13

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