Possible debug node status bug

General
1

When a debug node is configured to display its msg.payload in the node status, it seems to exhibit a peculiar (buggy?) behavior. When the node's enable button is toggled, it sends a status message that can be caught by the status node. In this flow, debug #1 sends a status message with status.text = "" each time the button is toggled. The debug #2 node does the same thing until it has received an input message. Then, if it is enabled, it sends status.text = msg.payload, then sends the same thing again when toggled off, and finally sends status.text = "" when toggled on again. Then it continues to alternate between the two messages with each press of the button. If the messages received by the status node are used to trigger other flows, this could generate some serious confusion during debugging. Has this been seen before? Is it really a bug?

[{"id":"4a5fef71.4edc8","type":"debug","z":"c357eda4.dd0a7","name":"debug #1","active":false,"tosidebar":true,"console":false,"tostatus":true,"complete":"payload","x":260,"y":60,"wires":[]},{"id":"1752cd2.1880b33","type":"status","z":"c357eda4.dd0a7","name":"","scope":null,"x":440,"y":80,"wires":[["2bdb75cf.30f55a"]]},{"id":"2bdb75cf.30f55a","type":"debug","z":"c357eda4.dd0a7","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","x":580,"y":80,"wires":[]},{"id":"7bd7a7e6.0734e8","type":"debug","z":"c357eda4.dd0a7","name":"debug #2","active":false,"tosidebar":true,"console":false,"tostatus":true,"complete":"payload","x":260,"y":120,"wires":[]},{"id":"caeb7d23.290478","type":"inject","z":"c357eda4.dd0a7","name":"","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":120,"y":120,"wires":[["7bd7a7e6.0734e8"]]}]

[EDIT]
Sorry, I forgot to mention that this happens with NR v0.19.5 on a mac with node v8.11.2 and on a Rpi with node v8.11.4.

Has anyone reproduced this?

2

My testing: same behavior as you described.
My opinion: seems to be somehow consistent as status.text always reflect the text displayed in the decoration. I can not imagine a different way of work.

What I find dangerous is the perpetual loop that will happen if you connect a debug node to the status node and configure this debug node to display its status. The status node will receive this event and will trigger a new message that in turn will generate another event... forever

r-01
r-01.png1170×370 19.2 KB

3

@Andrei, thanks for confirming that I'm not (completely) crazy.

Consistent, perhaps, or consistently wrong, since I don't see why just pushing the enable button when no status is displayed (either before or after) should trigger an event.

I hadn't thought of that. Kudos for an evil imagination.

4

ah, I see your point now. I agree with you. It is questionable if toggling the buttom (off to on) should clean up the text status decoration (which is ultimately what generates the event, I suppose). I have a flow that uses the status node to trigger another flow. i will check them when I got a chance (it is on a raspberry not accessible now). Based on your findings I will probably add some additional logic to trigger the flow only when text is not empty.

5

Hi, yes I can't quite remember why we left re-enabling the status to flush the status. The button subtly changed it's meaning from go/pause for the node - to only being go/pause for the output to the sidebar. If status is turned on it gets the status regardless (like the option to send to console log).

Having the button clear it is the only way we could flush it... but is somewhat inconsistent with what I also just said about being independent... so I guess we/you/us need to decide what it should do.

Also the loop is indeed a possible deadlock so yes needs thinking about.