# Should debug nodes be capable of passing the message forwards?

**URL:** <https://discourse.nodered.org/t/should-debug-nodes-be-capable-of-passing-the-message-forwards/95044>\
**Category:** Core Development\
**Created:** [1 February 2025 12:19 UTC](https://discourse.nodered.org/t/should-debug-nodes-be-capable-of-passing-the-message-forwards/95044 "2025-02-01T12:19:20Z")\
**Posts on this page:** 20\
**Page:** 3

<div class="post-metadata">

**Author:** ![ziga](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/ziga/32/98138_2.png) [@ziga](https://discourse.nodered.org/u/ziga)\
**Post date:** [2 February 2025 09:53 UTC](https://discourse.nodered.org/t/should-debug-nodes-be-capable-of-passing-the-message-forwards/95044/41 "2025-02-02T09:53:05Z")

</div>

> [@Steve-Mcl](#):
>
> A pass through debug has been on my wish list for some time (I've commented on this several times e.g: [Custom node appearance and event handlers. Proof on concept: Inline Gauge - #12 by Steve-Mcl](https://discourse.nodered.org/t/custom-node-appearance-and-event-handlers-proof-on-concept-inline-gauge/83001/12)) but there was push back due to loss of button. Personally I think it's time for a rethink on input or button/output or button exclusivity.
> 
> A promising new node log-io had this inline mode ([[Announce] node-red-log-io - #21 by Steve-Mcl](https://discourse.nodered.org/t/announce-node-red-log-io/94733/21)) but the author removed it as they were unsure of its value. I explained how it is a benefit for larger payloads (to avoid cloning) and the author is considering adding it back in.

Yea I see now that there is a winder interest in the pass through debug node so I'll be adding support for this back in into logIO node.

I'm considering adding an output node to existing logIO `inline` and `wired` modes.

- in case logIO is in `inline` mode, logIO behaves as core `debug` node, meaning it logs OUT messages of left connection node + passes messages forward
- in case logIO is in `wired` mode, logIO logs IN or/and OUT messages of all connected nodes + passes messages forward

All other logIO modes `all`, `select`, `flow` will remain as is, with only input wire connection.

Edit: nothing much can be done regarding button and output kinda overlapping each other in this case  
 ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/4/e/4e33229ffc94d4d2e0914e051815c1f5c385ca0d.png)

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [2 February 2025 10:02 UTC](https://discourse.nodered.org/t/should-debug-nodes-be-capable-of-passing-the-message-forwards/95044/42 "2025-02-02T10:02:43Z")

</div>

> [@ziga](#):
>
> Edit: nothing much can be done regarding button and output kinda overlapping each other in this case  
> ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/4/e/4e33229ffc94d4d2e0914e051815c1f5c385ca0d.png)

Yeah, this is why Dave pushed back (and why I said I think it's time for a rethink on node buttons) as there is a strong use case for having both input+button and output+button.

Fwiw, my image-tools viewer node has this arrangement because cloning images when viewing/debugging is super expensive. So you wouldn't be the first.

---

<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:** [2 February 2025 10:09 UTC](https://discourse.nodered.org/t/should-debug-nodes-be-capable-of-passing-the-message-forwards/95044/43 "2025-02-02T10:09:05Z")

</div>

> [@Steve-Mcl](#):
>
> Yeah, this is why Dave pushed back

Yup - still pushing back... this is my small hill to die on..  
looks really fugly (IMHO)... just don't do it.

---

<div class="post-metadata">

**Author:** ![ziga](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/ziga/32/98138_2.png) [@ziga](https://discourse.nodered.org/u/ziga)\
**Post date:** [2 February 2025 10:34 UTC](https://discourse.nodered.org/t/should-debug-nodes-be-capable-of-passing-the-message-forwards/95044/44 "2025-02-02T10:34:58Z")

</div>

Only other way I can think of atm to have a cake and eat it too is to look into annotations and to create custom svg button, similar to [flow-debugger](https://github.com/node-red/node-red-debugger/blob/main/src/flow-debugger.html#L894).

Not sure it's worth it though for just a visual effect.

---

<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:** [2 February 2025 10:38 UTC](https://discourse.nodered.org/t/should-debug-nodes-be-capable-of-passing-the-message-forwards/95044/45 "2025-02-02T10:38:43Z")

</div>

Just because I strenuously object to it doesn't mean you can't do it... but yes as this is debugging then something like the debugger would not be inappropriate.

---

<div class="post-metadata">

**Author:** ![jbudd](https://avatars.discourse-cdn.com/v4/letter/j/5f8ce5/32.png) [@jbudd](https://discourse.nodered.org/u/jbudd)\
**Post date:** [2 February 2025 10:43 UTC](https://discourse.nodered.org/t/should-debug-nodes-be-capable-of-passing-the-message-forwards/95044/46 "2025-02-02T10:43:43Z")

</div>

> [@TotallyInformation](#):
>
> To be honest, I'd settle for an intermediate where the debug node gets an extra flag. If set, it looses the switch and gains an output. ... you can already effectively turn off output by not selecting the option in the settings.

> [@dceejay](#):
>
> Simple POC of @TotallyInformation thought
> 
> ![Screen Recording 2025-02-01 at 17.18.36](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/2/b/2b39f037e4760b722f9f4c0afb0da944008c6c85.gif)

I don't personally like the idea that ticking or unticking a checkbox in the config can delete a wire in the flow.

But it's not so different from a function node's Setup tab where you can specify the number of outputs; if you reduce the number, wires are deleted.

Maybe a similar setup tab on the debug node for consistency?  
Obviously only 1 or 0 allowed!  
Or should this be on the Appearance tab?

These options both make it harder to use the more economical version of the debug node though.

Incidentally, why is the debug node's icon at the RHS?

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [2 February 2025 11:04 UTC](https://discourse.nodered.org/t/should-debug-nodes-be-capable-of-passing-the-message-forwards/95044/47 "2025-02-02T11:04:20Z")

</div>

> [@dceejay](#):
>
> looks really fugly

😄

I agree - unfortunately, there is a need. Short of redesigning nodes appearance (e.g. inset buttons) or adding a feature (like hover to reveal or right click context menu options) to nodes, we have little choice.

TBH, I really dislike that we have to deploy after toggling a button (especially the debug node). Dont get me wrong, i understand why it is the way it is but there are ways we could solve this. For example, a local store (of overrides) that can be updated without deploy would make the situation a lot smoother (storage on systems permitting) but I'm not trying to solve that here and now.

---

<div class="post-metadata">

**Author:** ![greengolfer](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/greengolfer/32/28276_2.png) [@greengolfer](https://discourse.nodered.org/u/greengolfer)\
**Post date:** [2 February 2025 11:21 UTC](https://discourse.nodered.org/t/should-debug-nodes-be-capable-of-passing-the-message-forwards/95044/48 "2025-02-02T11:21:50Z")

</div>

Is it more or less fugly ?

 ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/f/6/f682cf6f6099928c35b0c13a1173ecd9f3fc3174.png)

This is what I was suggesting above. The toggle on/off inside the node.  
The input/output wires are always there.

When the toggle is on, debug is available in the debug panel, if off, the debug node is a simple pass-through.

It means, that we don't need to rewire anything to add (activate) or remove (de-activate) debug.

---

<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:** [2 February 2025 12:27 UTC](https://discourse.nodered.org/t/should-debug-nodes-be-capable-of-passing-the-message-forwards/95044/49 "2025-02-02T12:27:00Z")

</div>

> [@Steve-Mcl](#):
>
> we have to deploy after toggling a button

err - no you don't "have top" deploy - it is flagging that the state of the flow has changed so there are changes - but you don't have to deploy. You can always hit ctrl-z if you want.

> [@Steve-Mcl](#):
>
> For example, a local store (of overrides)

do you mean (maybe) that the state of each debug node (and other nodes with toggles) is held purely in the client browser - so always off in the flow by default... (otherwise all would be on for every "new" client)... Interesting idea...

> [@greengolfer](#):
>
> Is it more or less fugly ?

Slightly less 🙂

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [2 February 2025 12:54 UTC](https://discourse.nodered.org/t/should-debug-nodes-be-capable-of-passing-the-message-forwards/95044/50 "2025-02-02T12:54:41Z")

</div>

> [@dceejay](#):
>
> > [@Steve-Mcl](#):
> >
> > we have to deploy after toggling a button
> 
> err - no you don't "have top" deploy - it is flagging that the state of the flow has changed so there are changes - but you don't have to deploy

You're right (as usual ;)) I'll me be more explicit. Once you toggle the debug, the workspace is marked dirty. Only a refresh or deploy clears this state. At this point my OCD kicks in and I need to deploy. Sometimes I don't want to deploy. Sometimes I may have actually made modifications that I really do want to deploy. The point is it's just a bit of a pain and suboptimal UX (IMVHO)

> [@dceejay](#):
>
> > [@Steve-Mcl](#):
> >
> > For example, a local store (of overrides)
> 
> do you mean (maybe) that the state of each debug node (and other nodes with toggles) is held purely in the client browser - so always off in the flow by default... (otherwise all would be on for every "new" client)... Interesting idea...

That is one option yes. But in this thought experiment I was thinking of a server local state store.

---

<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:** [2 February 2025 12:59 UTC](https://discourse.nodered.org/t/should-debug-nodes-be-capable-of-passing-the-message-forwards/95044/51 "2025-02-02T12:59:57Z")

</div>

> [@Steve-Mcl](#):
>
> server local state store

wouldn't that get really messy real quick when team editing ?

Re deploy - yes - it would be nice if click the toggle checked the undo history first and if it had already been toggled did an undo instead.

---

<div class="post-metadata">

**Author:** ![ziga](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/ziga/32/98138_2.png) [@ziga](https://discourse.nodered.org/u/ziga)\
**Post date:** [2 February 2025 14:06 UTC](https://discourse.nodered.org/t/should-debug-nodes-be-capable-of-passing-the-message-forwards/95044/52 "2025-02-02T14:06:30Z")

</div>

While on the topic of debug button (and probably other nodes with buttons) behavior, not sure if anyone noticed the following bug:

- if you deselect the button, debug node stops logging without a deploy (as intended)
- if you then reload the page, you get a warning about unsaved changes but you decide to ignore them
- upon page reload button is represented with active ON state as it was before changes were made (as intended), but actual state of the debug node is inactive - logs are off, although button represents active state

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [2 February 2025 14:19 UTC](https://discourse.nodered.org/t/should-debug-nodes-be-capable-of-passing-the-message-forwards/95044/53 "2025-02-02T14:19:56Z")

</div>

> [@dceejay](#):
>
> > [@greengolfer](#):
> >
> > Is it more or less fugly ?
> 
> Slightly less 🙂

Actually, it is probably significantly less accessible and non-touch friendly. Whether or not it looks "nicer" may be a moot point.

> [@Steve-Mcl](#):
>
> > [@dceejay](#):
> >
> > do you mean (maybe) that the state of each debug node (and other nodes with toggles) is held purely in the client browser - so always off in the flow by default... (otherwise all would be on for every "new" client)... Interesting idea...
> 
> That is one option yes. But in this thought experiment I was thinking of a server local state store.

But that would cause different behaviours on different browser even for the same user. I would politely suggest that is an even worse outcome?

> [@dceejay](#):
>
> > [@Steve-Mcl](#):
> >
> > server local state store
> 
> wouldn't that get really messy real quick when team editing

Or even testing on multiple browsers!

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [2 February 2025 16:05 UTC](https://discourse.nodered.org/t/should-debug-nodes-be-capable-of-passing-the-message-forwards/95044/54 "2025-02-02T16:05:36Z")

</div>

> [@TotallyInformation](#):
>
> > [@Steve-Mcl](#):
> >
> > > [@dceejay](#):
> > >
> > > do you mean (maybe) that the state of each debug node (and other nodes with toggles) is held purely in the client browser - so always off in the flow by default... (otherwise all would be on for every "new" client)... Interesting idea...
> > 
> > That is one option yes. But in this thought experiment I was thinking of a server local state store.
> 
> But that would cause different behaviours on different browser even for the same user. I would politely suggest that is an even worse outcome?

No it would be a much cleaner and better UX

As of writing (v3.x, v4.x): If you click to disable debug, server side stops sending messages (to all open clients). If you look at the the 2nd browser, the debug is enabled - but no messages are arriving. If I deploy the first, the 2nd does not know or reflect this change and you would be unaware there was a change until you deploy on the 2nd - at which time you are warned about needing to merge. In effect, by having the state in a server side store, anyone refreshing (or deploying) would not get a merge conflict and would (ideally) just get back the updated state. In an ideal world, the state change would actually be transmitted to open editors (meaning they could reflect the users choice - all without ever having to deal with the dreaded "merge"). In fact, a deploy is already communicated to all open editors today (you get a 5sec toast about changes been made) however you have to catch that, review it/merge it, refresh the page (potentially losing local changes) or face the merge issue when you deploy.

Example: I disabled the debug on the LHS and deployed. 10secs later, i look at the RHS and see the debug is enabled but there are no messages coming in! I decide to change something innocuous and I am faced with the merge toast.

![chrome_wXt3gEVDNC](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/3/5/3566774b2f6249a22938e730ba3ba8a78502bae3.gif)

Now play that out as server side state (instead of flow modification) and instead of displaying a toast about flows changed, the editor simply updates the state of the debug button on connected clients!

**EDIT**  
**For the record: This is a thought experiment - what I am suggesting may ultimately not be feasible**

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [2 February 2025 16:08 UTC](https://discourse.nodered.org/t/should-debug-nodes-be-capable-of-passing-the-message-forwards/95044/55 "2025-02-02T16:08:05Z")

</div>

> [@dceejay](#):
>
> > [@Steve-Mcl](#):
> >
> > server local state store
> 
> wouldn't that get really messy real quick when team editing

I think it would greatly improve things TBH Dave. See above post.

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [2 February 2025 16:14 UTC](https://discourse.nodered.org/t/should-debug-nodes-be-capable-of-passing-the-message-forwards/95044/56 "2025-02-02T16:14:57Z")

</div>

> [@ziga](#):
>
> - if you deselect the button, debug node stops logging without a deploy (as intended)
> - if you then reload the page, you get a warning about unsaved changes but you decide to ignore them
> - upon page reload button is represented with active ON state as it was before changes were made (as intended), but actual state of the debug node is inactive - logs are off, although button represents active state

Its not a bug, but a side effect of how the button state is persisted in flow json. This bolsters some of what I was talking about above.

---

<div class="post-metadata">

**Author:** ![ziga](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/ziga/32/98138_2.png) [@ziga](https://discourse.nodered.org/u/ziga)\
**Post date:** [2 February 2025 17:06 UTC](https://discourse.nodered.org/t/should-debug-nodes-be-capable-of-passing-the-message-forwards/95044/57 "2025-02-02T17:06:22Z")

</div>

> [@dceejay](#):
>
> Just because I strenuously object to it doesn't mean you can't do it... but yes as this is debugging then something like the debugger would not be inappropriate.

I know, just trying to find a good temp solution until we get core support to be more flexible with the UI.

What about this? 🙂

 ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/9/6/961297159e45c2097da6a2a301ea507b2cab3ef6.png)  
 ![Kooha-2025-02-02-19-11-40](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/1/f/1fc5e57bdbcca0db51133bfc85dd5dc26a9f525a.gif)

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [2 February 2025 18:00 UTC](https://discourse.nodered.org/t/should-debug-nodes-be-capable-of-passing-the-message-forwards/95044/58 "2025-02-02T18:00:39Z")

</div>

> [@Steve-Mcl](#):
>
> No it would be a much cleaner and better UX

Maybe I misunderstood what was being said. It looked as though the idea was to store the current on/off state in browser storage which would certainly result in different instances of the Editor having different behaviours.

I am certainly in favour of things that would make multi-editor use more consistent.

---

<div class="post-metadata">

**Author:** ![jbudd](https://avatars.discourse-cdn.com/v4/letter/j/5f8ce5/32.png) [@jbudd](https://discourse.nodered.org/u/jbudd)\
**Post date:** [2 February 2025 19:00 UTC](https://discourse.nodered.org/t/should-debug-nodes-be-capable-of-passing-the-message-forwards/95044/59 "2025-02-02T19:00:23Z")

</div>

> [@ziga](#):
>
> What about this? 🙂
> 
> ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/9/6/961297159e45c2097da6a2a301ea507b2cab3ef6.png)
> 
> ![Kooha-2025-02-02-19-11-40](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/1/f/1fc5e57bdbcca0db51133bfc85dd5dc26a9f525a.gif)

It's not very consistent with other nodes' appearance 😟

Or this for a testpoint node?  
Icon at the left.  
No button.  
Label defaults to not displayed.  
Hover tooltip shows label and debug status. (Accessibility feature?)  
Standard node status icon green/some other colour to visually indicate output to debug pane is en/disabled.

 ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/6/a/6a009285cd1d0ce1c664d4f512fba7b93158f39b.png)

(Mockup cobbled together from a link call node with label turned off)

---

<div class="post-metadata">

**Author:** ![ziga](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/ziga/32/98138_2.png) [@ziga](https://discourse.nodered.org/u/ziga)\
**Post date:** [2 February 2025 19:43 UTC](https://discourse.nodered.org/t/should-debug-nodes-be-capable-of-passing-the-message-forwards/95044/60 "2025-02-02T19:43:47Z")

</div>

How did you envision to toggle debug/no debug state without a button?

For logIO I'll go with example above. Although nonconstant with other nodes, it's very non intrusive imho and still keeps all existing functionality. It's just an eye candy and looks better than having output port overlaying the button.

[Previous page](https://discourse.nodered.org/t/should-debug-nodes-be-capable-of-passing-the-message-forwards/95044.md?page=2)

[Next page](https://discourse.nodered.org/t/should-debug-nodes-be-capable-of-passing-the-message-forwards/95044.md?page=4)