Why does importing a clipboard with a subflow create a "new" identical but renamed subflow

General
1

Edit: Now that I know the behavior I observe is inherent to Node-RED, I reposted this over on the feature requests: Import a flow containing a subflow without unintentionally creating a duplicate subflow

I need to copy/paste a flow that contains a subflow. However, when I do this, nodered creates an identical subflow but appends (2) or (3) or (4), etc. to the end of the subflow name. So far I determined a very basic test subflow does not behave like this, but once I include an mqtt node, I get this behavior. I have an example flow below.

Take the example flow, import it, then import it again and you should find yourself with a subflow called 'test subflow' and another one called 'test subflow (2)'. You can try just deleting the mqtt node and then repeating this process and you will not get 'test subflow (2)', you will only have 'test subflow'.

I am seeing that node-red automatically renames the subflow and changes the id of the subflow. I'm just not sure what triggers the conflict when it imports it. Apparently having an mqtt node does this, but just having the function node does not.

*note: this flow does not really do anything, it's just a quick way to demonstrate the issue. thanks for your help!


[{"id":"df115b21.a9c4f8","type":"subflow","name":"test subflow","info":"","category":"","in":[{"x":562.9999942779541,"y":249.0000114440918,"wires":[{"id":"388c98ef.3128e8"}]}],"out":[{"x":847.9999980926514,"y":245.99999618530273,"wires":[{"id":"388c98ef.3128e8","port":0}]}],"env":[]},{"id":"ad02fcde.0f788","type":"comment","z":"df115b21.a9c4f8","name":"test subflow import","info":"test subflow import","x":738.0234298706055,"y":127.05468368530273,"wires":[]},{"id":"388c98ef.3128e8","type":"function","z":"df115b21.a9c4f8","name":"hello","func":"msg.payload = \"hello\"\nreturn msg;","outputs":1,"noerr":0,"x":705.7734375,"y":246.203125,"wires":[[]]},{"id":"5b73054.8c7c8fc","type":"mqtt in","z":"df115b21.a9c4f8","name":"","topic":"test","qos":"2","datatype":"auto","broker":"547471b5.d339","x":544.7734603881836,"y":339.32031631469727,"wires":[["388c98ef.3128e8"]]},{"id":"547471b5.d339","type":"mqtt-broker","z":"","name":"","broker":"localhost","port":"1883","clientid":"","usetls":false,"compatmode":true,"keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthPayload":"","closeTopic":"","closeQos":"0","closePayload":"","willTopic":"","willQos":"0","willPayload":""},{"id":"dc3259b7.f5bd38","type":"tab","label":"test main flow","disabled":false,"info":""},{"id":"5073cfef.7fabf","type":"subflow:df115b21.a9c4f8","z":"dc3259b7.f5bd38","name":"","env":[],"x":861.7734375,"y":198.15625,"wires":[["94067309.e00a"]]},{"id":"94d27430.3f8208","type":"inject","z":"dc3259b7.f5bd38","name":"","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":660.7734298706055,"y":198.56249809265137,"wires":[["5073cfef.7fabf"]]},{"id":"94067309.e00a","type":"debug","z":"dc3259b7.f5bd38","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","x":1095.773494720459,"y":195.3437557220459,"wires":[]}]
2

I should add that once you import the flow, if you do a literal copy/paste and not an export/import, the subflow is not renamed.

Also, in addition to the mqtt node causing the renaming, using an influxdb output node causes the same thing. This may indicated any node with communication to a network triggers this behavior?

The fact that you can copy/paste without issue seems to indicate that there is no actual conflict.

3

Copy/Paste and Import/Export are two very different actions.

When you copy an instance of the subflow, you are only copying the instance node. When you paste, you are pasting a copy of just the instance node.

When you export the Instance node, you are not only exporting the instance, but the full subflow definition to go with it.

When you import that flow, you are importing the subflow definition and the instance. Node-RED detects you are importing what appears to be a duplicate of a subflow you already have. The current behaviour is to import it as a distinct subflow - because that the easiest thing to do.

There is a plan to do a better job of this in the future - to let the user choose whether to import it as a copy, use the existing subflow definition, or replace the existing definition with the one being imported.

4

Thanks for the explanation. Is there a reason that having something like an mqtt node or an influxdb node makes Node-RED think it is a duplicate? If you do not have mqtt or influxdb nodes, then you can import without any trouble. I ask because maybe it would help with a workaround.

5

To be honest, I can't remember. I wrote the code for trying to detect duplicates 3+ years ago and not looked at it since. Nothing springs to mind that would explain what you are seeing. The fact they both involved network communication is pure coincidence - the editor doesn't know anything about that, it just has the json configuration to look at.

6

However, both are using config nodes. Could that be the cause?

I observed a similar behavior a while ago.

7

Just in case it helps someone, I have successfully removed all my input and output mqtt nodes from inside my subflow and tied them into a single input and a single output from the main flow. On the input I just have them going to a function that sorts by the mqtt topic. On the outputs I am setting the topics anyway, so I can tie them to a single output that then connects to a single mqtt node in the main flow. Now I can copy and paste subflows without duplicating them. It's not ideal, but it's also not too terrible.

Also, I have seen you can have exec nodes and write-to-file nodes that do not cause any issues with importing subflows. So far then, I have only observed mqtt and influxdb nodes that give issues. I am sure there are more, but at least the main programming nodes do not seem to create a headache.