# 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:** 1\
**Showing post:** 54

<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**

---

_[View the full topic](https://discourse.nodered.org/t/should-debug-nodes-be-capable-of-passing-the-message-forwards/95044)._