Under the dropdown on the Deploy button is a Restart Flows option. I had always assumed that, in terms of flow operation, this was effectively the same as restarting node-red. It seems not however. For example it does not clear context. Also D2 nodes' state is not cleared.
Is that by design? What should the behaviour be?
I don't really see the point of the feature if it does not do a 'clean' restart.
I am running the v5 beta of node red, but I assume this is not a change to previous behaviour.
This is particularly relevant to the D2 ui-chart node. When using msg.ui_update.chartOptions to tweak the eCharts options it is easy to get the chart options in a mess. Currently the only way of recovering that is to restart node-red.
Nobody else got any thoughts on this?
I have a restart node-RED (very) short flow - as in 3 nodes - that I use after updating nodes so I have never used the Restart Flows drop down, but having seen this and had a quick think about it, 'what does Restart Flows actually do then?'
That is a very good question. It would be good to get an informed reply to that.
I'm sure it must do something else as well, but for me it does this.
I expected it to revert to the last deploy, as reloading the page does, but nope.
The server is always running the last deploy, so I am not sure what you mean by that.
The restart action is mostly equivalent to a full deploy with no changes; the existing nodes are stopped, the flow configuration is reloaded from storage, and the nodes are restarted.
It isn't quite the same as a full shutdown/restart of the Node-RED process as context won't get cleared.
Drop any changes in the editor since deploying. As reloading the page does.
I see that MQTT nodes reconnect, but a dashboard chart does not get destroyed and re-created, is that what you would expect?
That will depend on how Dashboard handles config nodes being stopped/started and any associated state management. It feels like it should be a clean restart, but I'm not familiar with how the db nodes manage their state.
I was asking whether they should get destroyed and recreated. They don't. Which means that the only way of completely restarting a DB2 chart, which one has got in a mess by passing it inappropriate config via msg.ui_update, is by restarting node-red. Which is a pain.
If we can identify the part of code hanging on to state, we may be able to detect a restart and clean up accordingly. But assessing if this is the right thing to do is also important.
Yes, that is why I asked the question.
You'll be right 50% of the time... For all those that want to fully reset the context - there will be those who want it maintained...
True, which I suppose means that we probably won't change the current behaviour.
It would certainly be helpful to have a clearer statement in the docs about what this option does, does not and is supposed to do. If it restarts all nodes - what does that actually mean?
I assume that it means that each node's registerType function is re-run? This is really important for us to know. If that is the case, I also assume that the close event is triggered before registerType is re-run? Because if not, that would cause many issues. But at least node authors should be made aware that registerType may be called again via this process and that may happen without a reset of Node-RED's context variables.
As I said, it is mostly the same as doing a full deploy. The key difference is that rather than send undeployed changes from the editor to the runtime, the runtime will reload the configuration from storage.
It isn't a full restart of the runtime; it doesn't cause node definitions to be reloaded so registerType is not called again.
If there is a new restart feature or change that deletes context, please give a warning (or even possibility to hide/disable in settings) because this will lead to data loss and errors in some (our 
) running systems.
Do you mean that selecting Restart Flows is something that you regularly do in your running systems?
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy
