I was looking to replace a large switch node with many outputs, by using a link call in dynamic mode.
There is no return data required, as this just sends the stored state of many UI switches on a node red restart. It just iterates over the variable and sends the payload to each matching link in node.
This works fine, BUT if there are any link nodes within the flows, then NR becomes very unresponsive and eventually crashes.
It may be that fixed target link nodes are not supposed to be used within a link call flow, but I couldn't find anything that suggested that, and in any case it should be handled better
I do need the link nodes as UI switches need to pass payloads to other parts of the flows.
I guess if this is not possible I will have to go back to using a large switch node
EDIT: I guess I could use MQTT in nodes instead, but that seems a bit clunky!
I cannot see how link nodes would cause this. Please post a reproducable minimal flow.
Regarding your query, I am having trouble parsing your question so I will just state: So long as the message entering the link-out (return) node contains the original _linkSource, it should work. You can nest link calls, you can pass the msg through other link nodes, and so on. The only requisite is that the msg has the _linkSource property.
Steve, thanks for clarifying that, since I now know that internal links should work.
As it was late last night, I'm just looking at this again, to narrow down the issue.
For this use case (alternative to switch node) I don't need a return node, as there is nothing to return, ideally I just want to route the messages outward.
The problem arises with the nodes which are shown as disabled in the image above.
These nodes have TWO connections from the "inner" link out nodes, meaning that they cannot finish with 1 link return.
I will try and boil it down to a simple flow, to see if I can either work around or more specifically demonstrate to problem.
It might be that an enhancement to the link call could make it fire and forget with a zero timeout ?
So currently a zero timeout produces an instant timeout message.
As zero is not really a valid option, should the node not ignore the timeout in this case ?
I thought the requirement here was that 0 should imply no timeout, with no requirement for a return, so the node could be used as a dynamic link rather than a dynamic link-call.
Well I 'm not exactly sure what is being asked for but one statement suggested that a linked flow was being linked to by more than one link call node. This would mean that there would be 2 different _linkSource references which would cause a problem if returned to both link call nodes
There wouldn't, I am working on the assumption that there are two link call nodes calling the same link flow, therefore each link call would have a different _linkSource that has to be returned to the correct link call node
I've spotted a problem with disabling the timeout; the node tracks each message it sends so that when a response comes back it can send the response in the context of the message that triggered it.
If we disable the timeout, then that state will still accumulate in the node, never being cleared - leaking memory.
I've come to the conclusion that:
Link Call should not allow the timeout to be disabled - it always expects a response
The Link Out node should have a dynamic mode added to it to satisfy the dynamic link without a response case
