Hmm,... that'll teach me for trying to use TypeScript. Currently falling down the rabbit hole of discovering why TypeScript changes the case of filenames seemingly randomly. OSX (where I develop) is case insensitive, so I didn't notice.
I just installed Node-RED 2.0 and then the node "node-red-debugger" and it seemed like it installed, but it came up as not being installed in the palette manager. Yes, after I stopped and re-start Node-RED.
When I try to install it because it allows me to, it says "Module already loaded". I installed/updated Node-RED globally.
Upon testing setting a breakpoint. On another Flow Tab page I have some inject nodes with Repeat Intervals. These are showing up in the message box below and I have not set any criteria for them. There is also a reference value in the output showing a number. I'm guessing it is a countdown? ...
as you can see in the screen shot there are 10 in this page. And there are few on other pages as this was to simulate some data on the dashboard. I had to disable these inject nodes otherwise it fills up the display with each inject value that is NOT part of the breakpoint or related to the flow logic in any way. It's catching every instance of every inject node as it cycles. This is a bug. Or, how do you keep it from catching values from inject repeat nodes that you have set up and do not want to display the timeout?
The Timers are actually working behind the scene. That means you DO NOT get a pause of all the logic and stop time. You stop the flow only. That means you continue to get the logic that is based on timers to continue to fill up the message window.
You should also have some means to stop these timers from elapsing. I also have a boolean "Blinker" node that when activated, fills up the message window as it continues to do it's thing. The purpose is to capture instances and compare your expectations to the events. This works this way, but with exception to the logic on the timing still causing events that are still captured. This is why it fills up the message window when timed events expire and cause message events.... As the debugger works to show flow values and step through, you need to also halt the timers from causing events unexpectedly.
Perhaps you need a means to allow the event to send from the nodes with timers. or a means to "continue/pause" timer type functions if they drive the output. And yes, Isolate flows that you want to debug and let the rest continue working.
Sounds like it's on the roadmap, but anything you can do to not stop all flows is very welcome. E.g. can a breakpoint on message input just stop messages going into that node? Or the ability to just stop the flow the node is in. Otherwise doing any of this on a live installation is a real issue and often bugs only manifest themselves in the real thing.
NB: tangentially related, when nodes are missing at start-up, would it be possible to only stop the flows with those nodes as opposed to all flows? Sometimes after an upgrade this happens to me and then I have to go scrambling for the missing nodes like a madman...
I'm wondering, If the breakpoint is tripped, then all should stop/capture with messages. then the breakpoint is reset or > Go, then the system works until the breakpoint is tripped again. I'm guessing I don't know how this is planned to work and that's causing confusion. I am not setting this up to do it correctly because I'm not using it right.
By the way, Great work! it will be very useful if you filter messages and keep it from stopping the browser page. There should be a means very much like the debug node display filter. Turn everything ON/OFF by flow or turn them all OFF/ON/ select individually.
No. The breakpoint remains active so if you resume the flows and a message arrives at it, it will cause things to pause again.
You can disable a breakpoint by clicking on it in the workspace, or unticking its checkbox in the list in the sidebar. A disabled breakpoint won't cause the runtime to pause.
I suspect with all your nodes running on timers continually injecting new messages it is overloading the debugger sidebar. Will need to think about how to handle that sort of continual load.
@knolleary ,
I also noted that a UPC-UA Node was reporting as I started the system. when i hit the breakpoint, at that time my message window was again flooded by the inputs coming from the Read Node.
Would it be considered to only capture the first events from these nodes? The purpose is to trap in time what is going on at the point when you pause the system. Right? Capturing messages that continue do not serve you because you now need to Disable it before hand.. or weed through the messages to remove those you do not want past the trip point.
The primary purpose of the Debugger is not as a Debug node replacement to simply capture messages as they flow through. The whole purpose is to pause the runtime so you can examine its state across various parts. And eventually let you modify a message so you can test/verify behaviours.
It is also the very first version - so yes, there's a huge list of things it could do. I've described the items I have planned. I'm sure there will be other suggestions. If anyone wants to help contribute with ideas, or better yet, code, then that would be welcome.
Nice! Just had a quick play and I'm sure it will come in useful.
For now, one tiny comment for maybe a future release: It would be nice to be able to click the breakpoint entries and be taken to the right node in the main editor. You can, of course go off to different places by clicking the node id in the messages display but finding your way back on a big set of flows can occasionally be challenging for those of us with aging memories.
