@node-red/runtime/flows/setFlows API rev check Issue?

General
1

Hi,
I'm trying to upload at run time a flows (collection of flow) using the setFlows function API but I got an unspecified stopping error.
Following the call stack in debug mode I've landed into @node-red/runtime/lib/api/flows.js where there is the setFlows implementation.
In the function I've found this check (lines 73-83) on flow's rev:

    if (flows.hasOwnProperty('rev')) {
      var currentVersion = runtime.nodes.getFlows().rev;
      if (currentVersion !== flows.rev) {
        var err;
        err = new Error();
        err.code = "version_mismatch";
        err.status = 409;
        //TODO: log warning
        return reject(err);
         }
  }

Obviously the importing flow's rev and the current flow's rev are different, and I enter in the error state.
I've deleted these lines and now I am able to load flows without error.

Why I should not load flows with a different rev version? This check is a bug?

2

Hi @fabik111

the api is described here: POST /flows : Node-RED

The important part is here:

If v2 of the API is being used, the request should include rev property that is set to the latest rev value known to the requestor. If this value matches the rev value of the active flows in the runtime, the request will succeed.
If it does not match, this indicates the runtime is using a newer version of flows and the request is rejected with a 409 status code. This allows the requestor to resolve any differences and resubmit the request.

The rev property your client sends should be the rev of the flows it last loaded from the runtime. This tells the runtime if the client is making updates on top of the latest flows, or if other updates have happened in the runtime that the client doesn't know about. This ensures a client cannot accidentally overwrite flows it does not know about.

The response of the request will include the new rev value for the flows that have been deployed.

This all only applies if you set the Node-RED-API-Version header to v2. If you don't provide that header (or set it to v1) then you can just provide the flow without the rev and you won't need to deal with the conflict checking.

3

Thank you for your response.
A couple of clarifications:

{
   user:'fabik',
   flows:{flows:saved.flows}, //saved is a flows object with flows and rev properties
 }

I had to add a layer flows because the function runtime.nodes.setFlows called inside setFlows has flows.flows as argument (@node-red/runtime/lib/api/flows.js line 84)

apiPromise = runtime.nodes.setFlows(flows.flows,deploymentType);

Maybe, in order to manage an object flows without rev, should be implemented an else branch like this:

 if (flows.hasOwnProperty('rev')) {
   var currentVersion = runtime.nodes.getFlows().rev;
   if (currentVersion !== flows.rev) {
     var err;
     err = new Error();
     err.code = "version_mismatch";
     err.status = 409;
     //TODO: log warning
     return reject(err);
  }
 apiPromise = runtime.nodes.setFlows(flows.flows,deploymentType);
 }else{
apiPromise = runtime.nodes.setFlows(flows,deploymentType);
}

Thank you again for your help
BR