[request]tab level deployment option?

We've got 3 options: everything (all nodes redeployed), flow level (that a node has been changed in) and just node level but no "all flows in this tab"

Would it be possible to add another one - all nodes in current tab?

Simon

I would find that useful, particularly if it can be selected even when no changes have been made.

That is so amusing -- I always thought the "Modified Flows" option DID refer to the current tab full of nodes!!! HAHAHA *sigh

I guess I missed the idea that only nodes connected to modified nodes were getting deployed.

Oh, these overloaded terms are really starting to bite back... so what the heck are you going to call this new option for deploying "all the nodes on this tab", since the word "tab" has been used in the past to refer to this "flow"? Look at the "Hamburger" menu -- there's an option to Export the "Current Flow" -- which by the way exports ALL the nodes on the current tab (uh, flow... uh, page? uh, hmmm).

Sorry for raising more issues than I have solutions! For me, the simplest (most expected) solution is to just change the behavior of the Deploy Modified Flows action. If it restarted all the nodes that I'm currently looking at it would be working as I always thought it did ;*) More importantly it would not require any UI changes to provide a solution to this request, albeit at a slight cost of restarting a few more nodes. But if that is way too much overhead, then perhaps the nodes should have been put on separate tabs anyway? Would anybody even notice the change, or am I the only one who was mistaken?

I don't think so :slight_smile:

I'm not even sure if I'm 100% correct (I've run tests and I think I'm right but am I? :slight_smile: )

No, I think you are correct.

But I guess the question is - what is the unique use case that would require you to only redeploy a single tab?

And yes, I also wish that we didn't have the overloaded "flow" term. I generally use "flow" to mean a connected set of nodes. But as mentioned, some of the UI uses different meanings.

Not got a unique one - but my main need for one is when there is an MQTT input node in one flow in a tab and I want it to redeploy when I alter nodes in other flows in the same tab

Simon

Ah, I see, you want the MQTT-in node to retrigger a flow even though MQTT hasn't changed the topic's value. Specifically when that node is not in the flow being changed.

I'll admit that might be occasionally useful actually. :slight_smile:

The purpose, from my point of view, is to get the mqtt node to send the values of retained messages again. Part of the problem is, I think, that there seem to be some flaws in the conditions under which the MQTT In node restarts. For example, if I have an MQTT In node feeding direct to a debug and deploy it I see the retained messages appear. If I then insert a function node between the mqtt and the debug and do a Flow Deploy then the MQTT In does not restart. If I then edit the function node and Flow Deploy again then it does restart. Also if I add an extra wire on the output of the MQTT node going somewhere else then again it does not restart.

Good points, and I believe the chain of "connected nodes" is also broken when passing through the link in/out nodes. I first noticed this when debugging the built-in swagger client -- if the http in was wired to an http response through a link node, or even a node with multiple outputs, then it was viewed as "not connected".