# Possible debug node status bug

**URL:** https://discourse.nodered.org/t/possible-debug-node-status-bug/7352
**Category:** General
**Created:** [29 January 2019 02:47 UTC](https://discourse.nodered.org/t/possible-debug-node-status-bug/7352 "2019-01-29T02:47:19Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![drmibell](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/drmibell/32/8424_2.png) [@drmibell](https://discourse.nodered.org/u/drmibell)
#### Post date: [29 January 2019 02:47 UTC](https://discourse.nodered.org/t/possible-debug-node-status-bug/7352/1 "2019-01-29T02:47:19Z")

</div>

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?

```auto
[{"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?

---

<div class="post-metadata">

### Author: ![Andrei](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/andrei/32/10446_2.png) [@Andrei](https://discourse.nodered.org/u/Andrei)
#### Post date: [29 January 2019 19:54 UTC](https://discourse.nodered.org/t/possible-debug-node-status-bug/7352/2 "2019-01-29T19:54:29Z")

</div>

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](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/2X/d/d74b8d42ad1362789488e827d34bf37032319b0c.png)

---

<div class="post-metadata">

### Author: ![drmibell](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/drmibell/32/8424_2.png) [@drmibell](https://discourse.nodered.org/u/drmibell)
#### Post date: [29 January 2019 20:05 UTC](https://discourse.nodered.org/t/possible-debug-node-status-bug/7352/3 "2019-01-29T20:05:31Z")

</div>

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

> [@Andrei](#):
>
> somehow consistent

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.

> [@Andrei](#):
>
> perpetual loop

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

---

<div class="post-metadata">

### Author: ![Andrei](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/andrei/32/10446_2.png) [@Andrei](https://discourse.nodered.org/u/Andrei)
#### Post date: [29 January 2019 20:16 UTC](https://discourse.nodered.org/t/possible-debug-node-status-bug/7352/4 "2019-01-29T20:16:40Z")

</div>

> [@drmibell](#):
>
> 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.

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.

---

<div class="post-metadata">

### Author: ![dceejay](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/dceejay/32/38_2.png) [@dceejay](https://discourse.nodered.org/u/dceejay)
#### Post date: [29 January 2019 20:27 UTC](https://discourse.nodered.org/t/possible-debug-node-status-bug/7352/5 "2019-01-29T20:27:35Z")

</div>

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.
