Persist Safe Mode

[Steve-Mcl]

Problem

Safe mode is great for recovering from a bad value or crashing due unhandled exception (surfaced by an incoming msg or bad node configuration) or an imported node/flow etc. However as soon as you deploy the changes, the run time kicks in.

This is problematic under the following conditions...

1. You didnt actually fix the issue (flows start running and you are back to square one)
2. You intentionally want to deploy but don't want the flows to start up
   1. e.g. to store progress for later or to pass on to another expert / reviewer

Proposal

1. Add a start up "safe mode" that is not exited upon deploy
   1. i.e. must be exited explicitly
2. Provide a means of entering and exiting this mode via an admin API
3. Provide an action / menu item to enter / exit this mode
4. ???? more ????

Side benefits

• Provides a pseudo means of suspending the runtime (on demand)
• Provides a means of designing flows over a long period without ever running (not finished, not ready, would conflict with another running flow/program)

Considerations

• Does the name "safe mode" suit this?
  • Should the feature be clearly and deliberately differentiated from safe mode considering the benefits?

[dceejay]

Immediate thoughts/questions....

1. what does Deploy button do/mean in this context ? Presumably just saves the flow. But if it hasn't fixed the problem then how do you know you haven't fixed it if it doesn't start running and crash again ?
2. errr - if the admin API stops the runtime... then how does it start again ? - And where does it start from ? clean slate ? where it was ? - sounds dangerous if other timeout are involved and start triggering on resume.

Is this not part of the step debugger ?

[wstam88]

Maybe it can automatically return to this "safe mode" when a crash occurs instead of completely stopping the runtime?

[dceejay]

How does it know ? Often you want safe mode when you end up in a tight loop - which you can't interrupt - so something would have to separately monitor for that... and sometimes you may actually be in a fairly tight loop and not want to be broken out of... all gets tricky

[Steve-Mcl]

@dceejay One of the major benefits is the ability to develop flows without them executing.

I have for some time needed a way to build flows & store them for later work or testing or for passing on to another user to further develop but they are not yet ready to be run. Sometimes even needing to develop on and store the flows for pushing to GIT (via projects) for another node-red to pull and use - but - without the backend running (the admin APIs), certain actions like opening credentials are not possible. Additionally, starting the flows is not desirable due to possible side effects / clashes (e.g. this 2nd developer instance makes a TCP connection that the external system considers a fail over connection, or, it has on start routines that would call an endpoint etc)

TBF: The title is probably not great but I suspect this is more organically turned into a different mode - perhaps "Develop Mode", "Suspended Mode" or "Runtime Stopped" is more descriptive?

From a UI POV, perhaps have a "Stop Runtime" and "Start Runtime" in the deploy menu?

[knolleary]

I think this summarises it well.

I think the "persist safe mode" framing doesn't position this properly.

The concept we want to explore is having the ability to stop the flows running from the editor - without Node-RED stopping.

Currently Node-RED will always be running the active flows - with the one exception of Safe Mode, where it doesn't start the flows until you do the first Deploy.

So we know the runtime has the ability to be 'live' without the flows running. The problem is you can currently only get into that state by restarting the whole Node-RED process with the appropriate envvar/flag set on the command line.

The proposal here is to have a new admin api end point that can be used to stop (and start!) the flows. The started/stopped state will be stored in runtime settings so that if the NR process is restarted, it returns to the same state (rather than always starting).

To move forward with this, we need to:

• propose the admin HTTP API for stopping/starting the flows
• define how Safe Mode interacts with this
• explore how these options can be exposed in the editor.
• define a settings.js flag to enable/disable this feature. Some embedded use cases for the editor may not want to expose this feature to their end users. If this lands in 3.0, it can be on by default - with an option to disable if needed.

[Steve-Mcl]

propose the admin HTTP API for stopping/starting the flows

Perhaps a generic endpoint that can be expanded in the future.
Something like /control/:action or /runtime/control/:action
type: POST
API: /control/:action
where action can be either start or stop

define how Safe Mode interacts with this

• If node-red is started with "safe mode", then when "stop flows" is operated, this makes the runtime enter "stopped" mode (flows state remains stopped but node-red enters "stopped mode" and therefore persistent until "start flows" is operated)
• If started with "safe mode", then "start flows" is operated, this makes simply starts the runtime (ends safe mode) just like a deploy (but without having to actually change anything)

explore how these options can be exposed in the editor.

• I would propose there are 2 actions. "Stop Flows" and "Start Flows" (or "Stop Runtime" and "Start Runtime") in the deploy menu
• 

define a settings.js flag to enable/disable this feature. Some embedded use cases for the editor may not want to expose this feature to their end users. If this lands in 3.0, it can be on by default - with an option to disable if needed.

How does "allowStopStart": true at the root of settings.js look?

[knolleary]

API design

Given the admin api endpoints sit at the same root path (by default) as used by HTTP In nodes, I'm very wary of adding whole new paths to the API as there is a very real chance of a clash of paths.

Given the resource we'd be operating on are the flows, I think we could safely hang it under the existing /flows endpoint - this feels semantically okay and avoids the risk of a clash.

There are lots of ways we could approach this. Applying an action API to a restful API is one of those things that divides opinion on how it should be done

• POST /flows/action {"state": "start|stop"}
• POST /flows/actions/start /flows/actions/stop

As we also need an endpoint to query the current state, it makes sense to have an API that can have a GET method on as well. On that basis, I don't think /flows/actions/:command is appropriate. Nor is action the right resource name to use in the GET case.

On that basis, I propose:

• POST /flows/state - {"state": "start|stop"} (with scope for other options in the future)
• GET /flows/state - return the current state object

That makes /flows/state a Thing that can be modified and queried - so feels right to me from a RESTful POV.

UI Design

I think there should be a single entry in the Deploy menu that is either start or stop - depending on the current state.

We already have a runtime-state event (iirc) that gets sent over the Comms connection - this is how the editor is told the flows are stopped due to missing nodes (for example). We will need to ensure that event is also properly used to communicate the start/stop of flows.

Currently the UI will show a warning notification for stopped flows (because it is an error condition or safe mode enabled). We need to decide what notification is appropriate if the user has requested to stop the flows. There is certainly a concern that a user gets confused that their inject buttons/debug aren't working because they don't realised the flows are stopped.

There are certainly use cases where 'flows are stopped' is the normal expected state - so having a permanent UI notification wouldn't be helpful.

This feels like one of those items I need to play around with once we have the basic API and menu item working.

Settings file

There does need to be a flag in the settings file for this - not sure allowStopStart is quite it, but for the sake of getting something working, its a start.

[dceejay]

This seems to be moving away from deploy frame of mind to a good old fashioned load/edit/save file and stop/start the runtime type of approach. If it is part of trying to split out the editor to be able to run that standalone that is one thing but I'm not sure how common this use case/requirement is... Is there a lot of pull for this to add so many extra buttons/options to the deploy menu ? How does this work if others are also editing the flow ? is it stopped for all or does one user have master stop / start control ?

[knolleary]

There is nothing in this proposal about load/save. It is only about being able to have the runtime active without the flows running.

If it is part of trying to split out the editor to be able to run that standalone that is one thing but I'm not sure how common this use case/requirement is..

Yes, that is one use case. It might not be common for the everyday Node-RED user, but for the use cases that need it, they really need it and the lack of it makes it hard to work around.

Is there a lot of pull for this to add so many extra buttons/options to the deploy menu ?

My proposal is one extra button - a start/stop toggle

How does this work if others are also editing the flow

It just works. They are notified the flows are stopped. They can carry on editing and deploying changes.

is it stopped for all or does one user have master stop / start control ?

As you know, we don't have different levels of permissions for users who can edit the flows. There is nothing in this proposal that changes that. Any user with edit permission would be able to start/stop the flows.
That doesn't preclude us from adding more role based security in the editor in the future... Just not a consideration for today.

[dceejay]

nothing in this proposal about load/save.
deploy while stopped sounds like file-save to me ?
If the use case is not that common then should it be behind a settings option rather than in everyones deploy menu ?
Steve's proposal was two more buttons.
OK - re multi-user - another thing to be cognisant of so as not to upset your co-workers :-)
Is the running state stored at the server end ? so someone can forget to re-enable the production flow ?

[knolleary]

nothing in this proposal about load/save.
deploy while stopped sounds like file-save to me ?

We are not introducing the idea of files... Or the idea of opening a different set of flows. That's project mode we already have.

If the use case is not that common then should it be behind a settings option rather than in everyones deploy menu ?

Yes. The proposal explicitly says this feature would be enabled via the settings file. whether it is enabled by default (because it's a useful feature everyone could benefit from) or off by default and we see what the response is from the wider community.

Is the running state stored at the server end ? so someone can forget to re-enable the production flow ?

Yes, it has to be saved in the runtime so it can restart in the right state. And yes, a user could leave their flows stopped and go on holiday by mistake.

[Steve-Mcl]

Link to PR: node-red/node-red#3642