Deploying the state machine node does not change its status

General
1

I was under impression that by adding a node to a flow, or moving a node, and deploying the flow through Deploy-Modified Flows the flows containing nodes marked with blue circle should restart.

It does not seem to be always the case.

Import the following flow:

[{"id":"a1b23951.ce6a58","type":"tab","label":"State machine example","disabled":false,"info":""},{"id":"721c9d74.48aec4","type":"state-machine","z":"a1b23951.ce6a58","name":"","triggerProperty":"topic","triggerPropertyType":"msg","stateProperty":"topic","statePropertyType":"msg","outputStateChangeOnly":false,"throwException":false,"states":["initial","updated"],"transitions":[{"name":"update","from":"*","to":"updated"}],"x":300,"y":100,"wires":[["e8c4a0eb.cc77d"]]},{"id":"2806cff8.27fd6","type":"inject","z":"a1b23951.ce6a58","name":"","topic":"update","payload":"updated payload","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":150,"y":40,"wires":[["721c9d74.48aec4"]]},{"id":"cafda122.04bfa","type":"debug","z":"a1b23951.ce6a58","name":"payload","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","x":820,"y":220,"wires":[]},{"id":"57e3d16a.d9ba1","type":"change","z":"a1b23951.ce6a58","name":"payload → \"initial payload\"","rules":[{"t":"set","p":"payload","pt":"msg","to":"initial payload","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":600,"y":120,"wires":[["cafda122.04bfa"]]},{"id":"e8c4a0eb.cc77d","type":"switch","z":"a1b23951.ce6a58","name":"","property":"topic","propertyType":"msg","rules":[{"t":"eq","v":"initial","vt":"str"},{"t":"eq","v":"updated","vt":"str"}],"checkall":"true","repair":false,"outputs":2,"x":370,"y":160,"wires":[["57e3d16a.d9ba1"],["cafda122.04bfa"]]}]

image
image2512Ă—650 70.8 KB

Deploy it:

image
image2508Ă—650 80.5 KB

Inject the message to update state machine state:

image
image2510Ă—656 92.9 KB

Modify the flow without modifying the node (e.g., move the node, or add a new node not connected to the rest):

image
image2508Ă—660 93.8 KB

Deploy using Modified flows or Modified nodes option:

image
image2514Ă—666 104 KB

Result: the state machine remains in the updated state and announces it instead of starting in initial state.

As a bonus, in the above example, I get a message with undefined payload.

If I did the same using used Deploy-Full instead, the state machine would reset to initial state and send the message with Initial payload.

So, either of the following causes the state machine node to reset back to the initial state:

  • Deploy-Full
  • Deploy-Restart Flows
  • modifying the actual flow (connected to the state machine), other than moving the nodes (e.g., changing a name, deleting and recreating a connection) and deploying with any option (full, modified flows, or modified nodes)

but not:

  • Deploy-Modified Flows
  • Deploy-Modified Nodes

I'm not sure if it's a problem with the state machine node, or a general one, but it looks buglike to me.

Whether I tamper with the state machine node by moving it, or renaming it, I get the same blue circle indication in the editor, yet the results of Deploy options differ.

What do you think?

2

Just moving a node does not count as it being 'modified' for the purposes of deciding what gets restarted. Only a material change to the nodes configuration will get counted.

3

Fine.

Then:

  1. When a node is moved:

    • Why does the Deploy button activate? Pressing it does nothing, according to the above.
    • Why does the blue circle appear on the moved node?

  2. When an unrelated node is added to a flow:

    • Why does the description for the Deploy-Modified Flows say "only deploys flows that contain changed nodes"? When in fact it does not "deploy flows that contain changed nodes", but acts the same as the Deploy-Modified Nodes

It's inconsistent, imho.

4

Because you want to save the change.

This was done based on user feedback. Users wanted to be able to 'tidy up' their flows by repositioning the nodes and be able to save the change, without disrupting the running nodes.

In this context, 'flow' means a collection of nodes that are wired together. It doesn't mean the tab in the editor.

5

Fine.

It wouldn't hurt if a "material change," as you called it, caused the circle to be e.g., yellow, and other changes - blue.

See? I just told you it's inconsistent. :slight_smile:

6

Errrr, but after second thought, not really "fine."

The screenshots, which I posted in my initial message, show that by moving the state machine and pressing Deploy-Modified Flows, the node injects a new message (with its current state).

It should not, if "moving a node does not count as it being 'modified' for the purposes of deciding what gets restarted."

So just by moving the node and deploying changed flows, which you said was just to save a layout, I actually did somewhat (re)start it.

Quoting the state machine docs:

At start up, the node will emit a message with the initial state if the state output property is set to a msg property.

It emitted a message with the state, but not entered the initial state.

7

you may need to check with the author of that node.

8

Maybe. So far I'm trying to figure out what is happening there.

If as @knolleary suggested, Node-RED does nothing but saving a layout, unless there was a material change in a node, then how does this state machine node emit a message?

The node doesn't capture editor's UI button actions and act on its own, does it?

9

So yes - looking at the code - https://github.com/DeanCording/node-red-contrib-state-machine/blob/master/state-machine.js#L98
For some reason he is hooking to the overall start message

RED.events.on("nodes-started", node.startup);

So fires his start message on every deploy... not just flow or node specific ones...

2 Likes
10

Okay.

Please bear with me, I'm using Node-RED for less than a week.

So this is a runtime event as described here, right?

Where can I see the types of events?

And when Debug-Modified Flows is pressed - what event does it produce?

11

As the line of code suggests it emits a "nodes-started" event.
If a node listens for that general message it is up to the node to handle it appropriately.

12

My understanding (but please check with the author) is that the message being sent is the one the state machine would send when entering the initial state. From the README:

The node will always start in the first state on the state list and will emit a message with the initial state if the state output is set to a message property.

This behavior makes sense for a state machine that is programmed to perform an entry action (in this case, sending a message) when it makes a transition into a new state. Treating a startup as an entry into the initial state allows any downstream nodes to know the state of the machine and is consistent with the subsequent behavior of the machine.

13

Does this event mean that the entire flow has been deployed and is ready? Could I use it in a contributed node to hold off displaying the initial status of the node until any status nodes in the flow are ready to catch that status? (See the discussion in this thread.)

14

no - it means all nodes have been asked to start. It doesn't mean they have started - nodes that do async initialisation (like making connections) may take a long time to start (or indeed never complete).

15

Yes. And I can't find anything about nodes-started on nodered.org except for five messages on the Discourse. Hence my question.

I assume it is a Node-RED's message -- where can I find anything about it? And about other events that are emitted?

16

It's part of an internal API so not documented. It is not expected for nodes to use this directly.

17

Thanks. You've answered my first question, but about the second: if the status nodes start up synchronously, could listening for "nodes-started" still help?.

18

OK, I withdraw my annoying questions...

19

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