Make setting an id in Post flow work

Core Development Feature Requests
1

As discussed here

currently setting id in post flow does not work, also mentioned in the API itself

The runtime will assign a new id for the flow. If the provided flow configuration object includes an id field it will be replaced and the z property of all nodes updated to match.

I would like to request setting id will set an id, and not setting it will create some different random id.

For example (I use Postman)

Sending post request to http://localhost:1880/flow with raw JSON body

{
  "id": "aabb",
  "label": "Flow 14",
  "nodes": [ ],
  "configs": [ ]
}

will make the new flow id aabb.

2

I have written the code and tested it (can be found in my fork) in case this feature will get approved.

3

But what you've suggested will break the behaviour Nick described as the original use case.

It would also be a breaking change to the published API documentation, so could not be shipped before version 4.0.0 at the earliest and even then changing the behaviour of an existing API to effectively do the opposite of what it previously did would need a very compelling reason.

You've not explained why what you propose is better and why you can't just use the response from the post which includes the new id.

4

Unfortunately, I don't have a "very compelling reason" :sweat_smile: but I can share my side and thoughts.

Background:

I am part of a team that creates an open-source smart home platform that is based on Node-Red to manage the automation part.
A big part of it lets users create automation in the app with a simple UI and it will create the automation inside Node-Red.
By creating automation inside Node-Red I am granting the user a visual representation of the automation for changes and an advanced tool for pro users who can learn all Node-Red endless power to customize each automation.

My Case:

In the smart home platform that I am part of the automation is first created in the app with the unique id and then sent to the hub which constract it inside Node-Red using the API and keeps track of it in case the user wants to interact with it, activating automation (scene) or changing it straight from the app.
Making the unique id of the automation the same as the flow-id makes sense as they are talking about the same thing and it is a consistent id.
If there is an error or users decided to change something I have the option to create the same automation again (down to the id of the flow) without updating all of the references to it everywhere with the new flow-id which gets created for me automatically each time.
Moreover, requests to the smart home API about automation can easily be tracked back to the correct flow.
And vice versa, users that have a stronger Node-Red foundation can use the flow-id to easily interact and connect new automation with existing ones.

All of what I said can be done without the change, but by having control of the flow id I have the option to make my program consistent, more stable, and better track and interact with automation.

More Incentives:

It will also make the API cleaner and will reduce the amount of confusion and unexpected behavior of the API.
Whenever API includes certain fields (without reading all of its descriptions) as a developer I assume that this field/option does something which I can control, I think that having it there just to be totally ignored is unexpected behavior and is bad practice.

Changing that will brake the API and the fix for developers will be very simple, just remove the id field and it will do the same as before, so just a simple fix for the brake.

It can also be seen as a new feature that got added to Node-Red, this way there is more control for developers while using and interacting with Node-Red for different reasons than mine.
And the change to achieve this new feature is minimal.

5

Still not convinced it's worth potentially breaking anybody else that uses this endpoint.

And as I said, even if it was changed, it will NOT ship before version 4.0.0 since we can't make breaking changes in a existing release, so you are going to need to implement a work around until then (at the very earliest mid next year)

Suggestion:
You create a temporary ID when you create the automation in your app, and replace it with the value you get back from the POST on success. Since it's a new thing at that point it shouldn't be referenced from anywhere else yet, so it should only need updating in one place.

6

"Version 4.0.0 at the very earliest mid-next year" is ok by me since this is a project that will continue getting developed and will get improved as time goes by, and when a better/fitter way is ready we will use it.

This is the best option for the long run so I will implement some workaround for now to make stuff work and will change it in case it got accepted.

7

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