I've hit an issue where inconsistent stuff happens in my nodes after I add a new parameter and I tracked it down to the fact that existing nodes in flows don't get upgraded. Take a very simple node definition:
RED.nodes.registerType('test',{
category: 'test',
color: '#A12100',
defaults: {
name: {value: ''},
param_one: {value: "123"},
},
inputs: 1,
outputs: 1,
label: 'test'
})
This node has one parameter (other than name): param_one
On the node.js side I have:
function test(config) {
RED.nodes.createNode(this, config)
RED.log.info(`Test node config has: ${Object.keys(config).join(' ')}`)
}
If I instantiate one of these nodes, it prints the expected:
10 Aug 17:12:34 - [info] Test node config has: id type z name param_one x y wires
If I now add a new parameter, e.g.:
defaults: {
name: {value: ''},
param_one: {value: "123"},
param_two: {value: "456"},
},
Restart Node-RED and I still get:
10 Aug 17:12:34 - [info] Test node config has: id type z name param_one x y wires
So if in other parts of my code I expect config.param_two
to exist or to have the default value 456
then that will fail for nodes created prior to the addition of param_two
.
If I now reload the flow editor, add some random other node, and do a full deploy, there is no change, the flow editor did not add the default param_two
to the pre-existing test nodes. The only way to get param_two
added is to manually edit every test node, change something, and then deploy.
I understand why all this happens, but IMHO it's quite bad behavior. It leads to very subtle bugs that are basically impossible to track down once in the field because they depend on prior flow configuration and time of node upgrades.
In addition, to defend against this type of issue, one has to explicitly repeat the default values, which is also a great source for errors down the line. E.g., on the node.js side the constructor for the test node would have to include something like
if (!('param_two' in config)) config.param_two = 456
IMHO the best solution would be for the runtime to add the missing default values at start-up. But the runtime doesn't have the data for this... The next best thing would be for the flow-editor to add the missing default values to existing nodes and mark them as dirty.