[q-gate]Feature Request - 2nd debug output

@drmibell Hi Mike
Just had an (maybe a bit OTT) idea pop into my head so I thought I'd get it out there before it vanishes :slight_smile:

A lot of the time - I use q-gate to hold messages back during testing/debugging flows

It would be nice to direct stuff to a 2nd output that could be sent to a debug node instead of the normal output

That way, we can examine the queued messages without them being sent onwards to the next real node in the flow

If you think this sounds OK to you but you're busy - I'd be willing to try implementing it and let you see the results before doing a PR - if I can get it to work nicely that is :slight_smile:

Initial idea is have a toggle in the UI to select single/double outputs and then use a control messages to direct the node output to main or the debug one

1 Like

Do you mean all output (while switched) would go to the second output instead of the first one, but everything else is the same? Or something more complex than that?

My idea is for all output to be switched so you can do what you want with peeking/releasing one message at a time to see what's in the queue

Or anything else.

Like I said - this is for when I use a q-gate to stop testing messages going onto things like twitter nodes.

it would be great to switch the output away from its normal destination during early debugging testing

Oh I see. So you could peek at it via o/p 2 and then decide whether to delete it or release it on o/p 1.
Would that flow be any simpler than using a node on the output that checks each message and either bins it or passes it on?

That would be a good use for it :slight_smile:

Well this is intended for Mark I eyeball debugging :slight_smile:

So you'd temporarily divert the output of node from normal to secondary output port and (most likely) send that to a debug node.

It saves having to disconnect the real output - do a reploy - then do your checks/inspections on the queded messages

I'll knock up a prototype suffix node to show how I envisage it working

At the moment you can only peek the next one to be released, so if you want to see more than that then you won't later be able to release them on o/p 1. Perhaps you don't want to do that but just want to watch them for a while before deciding they are ok and then switching to o/p 1. So basically the same as disconnecting the output and sending it to a debug node and then, after checking, restore the connection.

Exactly :slight_smile: but without the need to disconnect - redeploy - test - reconnect and redeploy again

You can just switch back and forth at with an inject control node (or a pair of them)

As in this flow:

[{"id":"bbb40586.0165c8","type":"q-gate","z":"eb950a0f.0fc638","name":"","controlTopic":"control","defaultState":"open","openCmd":"open","closeCmd":"close","toggleCmd":"toggle","queueCmd":"queue","defaultCmd":"default","triggerCmd":"trigger","flushCmd":"flush","resetCmd":"reset","peekCmd":"peek","dropCmd":"drop","statusCmd":"status","maxQueueLength":"100","keepNewest":false,"qToggle":false,"persist":false,"x":290,"y":380,"wires":[["dfc30fba.91ba48"]]},{"id":"dfc30fba.91ba48","type":"switch","z":"eb950a0f.0fc638","name":"","property":"debug","propertyType":"flow","rules":[{"t":"eq","v":"false","vt":"jsonata"},{"t":"eq","v":"true","vt":"jsonata"}],"checkall":"true","repair":false,"outputs":2,"x":410,"y":380,"wires":[["95c755ac.e40e5"],["dceda48b.b6fb68"]]},{"id":"2db31376.109324","type":"inject","z":"eb950a0f.0fc638","name":"","topic":"","payload":"","payloadType":"date","repeat":"2","crontab":"","once":false,"onceDelay":0.1,"x":150,"y":380,"wires":[["bbb40586.0165c8"]]},{"id":"95c755ac.e40e5","type":"debug","z":"eb950a0f.0fc638","name":"normal output","active":false,"tosidebar":true,"console":false,"tostatus":true,"complete":"payload","targetType":"msg","x":600,"y":340,"wires":[]},{"id":"dceda48b.b6fb68","type":"debug","z":"eb950a0f.0fc638","name":"debug output","active":false,"tosidebar":true,"console":false,"tostatus":true,"complete":"payload","targetType":"msg","x":600,"y":420,"wires":[]},{"id":"60d5eadd.96c9bc","type":"debug","z":"eb950a0f.0fc638","name":"debug enabled","active":false,"tosidebar":true,"console":false,"tostatus":true,"complete":"$flowContext('debug')","targetType":"jsonata","x":440,"y":480,"wires":[]},{"id":"7d1f8d98.1fbbe4","type":"inject","z":"eb950a0f.0fc638","name":"toggle","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":130,"y":480,"wires":[["9e7c377c.503bf"]]},{"id":"9e7c377c.503bf","type":"change","z":"eb950a0f.0fc638","name":"debugging","rules":[{"t":"set","p":"debug","pt":"flow","to":"$not($flowContext('debug'))\t","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":270,"y":480,"wires":[["60d5eadd.96c9bc"]]}]

What you want to do makes sense, but I'm not sure it calls for brain surgery on the q-gate node.

well ... it would save 2 extra nodes and pollution of the flow context space :slight_smile:

But, in the meantime, I'll just add a custom function node and wrap the two into an invisible group and then come back and raise the issue again after I prove that its an invaluable debugging tool :slight_smile:

#EvenMadderIdea - I'll raise a PR on the switch node to do the job.............. :laughing:

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.