[FR / PR] Click on id in debug panel highlights node or flow

[ralphwetzel]

Quite regularly I find myself putting the id of a node or flow in a msg for debugging. To find this node / flow in my editor, I'm then copying this id & enter it in the search box. Works - but is a bit inconvenient.

I'm proposing to build upon an already existing feature and allow to find & highlight a node or flow on click of its id in the debug panel:

Would you accept a PR?

[cymplecy]

Just curious - how do you add add node.flow id into a message?

[ralphwetzel]

node.path @ function node == flow_id/node_id

[cymplecy]

I've read this a few times now and I'm still clueless

[zenofmud]

@ralphwetzel what node is that test node?

[Steve-Mcl]

@cymplecy

I've read this a few times now

So what @ralphwetzel is sating, it will give you flow_id followed by a / followed by the node_id

So you can split that down further

const [flow_id, node_id] = node.path.split('/')
msg.payload = { node_id, flow_id }
return msg

or long hand if it helps

const path = node.path.split('/')
const flow_id = path[0]
const node_id = path[1]
msg.payload = {}
msg.payload.flow_id = flow_id
msg.payload.node_id = node_id
return msg

[{"id":"2a920c7a7ebdae7d","type":"inject","z":"6e46a349d744ceaa","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":2220,"y":400,"wires":[["f35955cb00abb022"]]},{"id":"f35955cb00abb022","type":"function","z":"6e46a349d744ceaa","name":"long version","func":"// long hand\nconst path = node.path.split('/')\nconst flow_id = path[0]\nconst node_id = path[1]\nmsg.payload = {} \nmsg.payload.flow_id = flow_id\nmsg.payload.node_id = node_id\nreturn msg\n\n\n","outputs":1,"timeout":30,"noerr":0,"initialize":"","finalize":"","libs":[],"x":2260,"y":440,"wires":[["bff1bb750c152bee"]]},{"id":"bff1bb750c152bee","type":"debug","z":"6e46a349d744ceaa","name":"debug 316","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":2310,"y":480,"wires":[]},{"id":"d8334fc65d995f1c","type":"inject","z":"6e46a349d744ceaa","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":2220,"y":560,"wires":[["ee1c5158c66e0dc4"]]},{"id":"ee1c5158c66e0dc4","type":"function","z":"6e46a349d744ceaa","name":"short version","func":"const [flow_id, node_id] = node.path.split('/')\nmsg.payload = { flow_id, node_id }\nreturn msg","outputs":1,"timeout":30,"noerr":0,"initialize":"","finalize":"","libs":[],"x":2260,"y":600,"wires":[["7c3f71ea112df2af"]]},{"id":"7c3f71ea112df2af","type":"debug","z":"6e46a349d744ceaa","name":"debug 317","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":2290,"y":640,"wires":[]}]

[Steve-Mcl]

@ralphwetzel

I'm proposing to build upon an already existing feature and allow to find & highlight a node or flow on click of its id in the debug panel:

How would you propose to determine a string is an id? what would be the criteria to perform a node lookup? Would it be specifically if it is a property named flow_id or node_id? Would it be applied to anything that looks like an ID?

[dceejay]

seeing as we all already have ._msgid - should they not be ._sourceid and ._flowid ?

Then again - one of the tenets of flow programming is that nodes should be as independent as possible - ie not care where a message came from... adding the source to any message would break that in that flows could/would start to exploit that.

I guess we need to clarify the proposal - is this intended to be baked in so all msgs carry this - or just some random property as required - and then as per Steve's question do you just guess/assume any 16 char hex like string could be a link ?

[ralphwetzel]

@Steve-Mcl

How would you propose to determine a string is an id? what would be the criteria to perform a node lookup? Would it be specifically if it is a property named flow_id or node_id? Would it be applied to anything that looks like an ID?

The proposal takes the string, checks if it matches the id of a flow or node and the creates the functionality.

[dceejay]

So it has to check every property of every msg to see if it is node/flow id like ? How does that affect performance in high volume flows ?

[ralphwetzel]

No, it's only checking properties of type string.
Compared to the amount of processing already done to create the debug message for the sidepanel, it looks to be neglectable.

[dceejay]

maybe only check those at top level directly under msg. ?

• currently I'm processing video metadata - so 25 fps, that ends up as 35-50 text properties... (all under payload).

[ralphwetzel]

One of my contrib nodes.

[ralphwetzel]

@dceejay

maybe only check those at top level directly under msg. ?

As the feature is implemented in the process to build the debug msg output, it follows its standard creation procedure. Thus a property is populated only if visible to the user = toplevel or expanded. Consequentially the mentioned check is done as well only in those cases.

[TotallyInformation]

I do feel that this has the potential for unnecessary overheads and core code complexity. It would be easily resolved if, as previously suggested, there was an agreed naming convention. Then no limits or workarounds would be necessary.

[ralphwetzel]

@TotallyInformation

there was an agreed naming convention.

How does a naming convention help you finding a node (visually) in a number of flows - based on its id?

@TotallyInformation

core code complexity

It's about 10 additional lines in a file of 1500.

[TotallyInformation]

@ralphwetzel

How does a naming convention help you finding a node (visually) in a number of flows - based on its id?

That misses the point. The point being why should the debug panel processing be forced to check every string value to try and guess whether it contains a flow or node id? It should not.

Having an agreed naming convention side-steps that issue completely.

@ralphwetzel

It's about 10 additional lines in a file of 1500.

That has to be run against every string value in every debug output? When the debug panel can already be quite an overhead. And the number of lines also somewhat misses the point that every entry has to be tested to see if it as string and then has to work out if that string is a flow or node id? Doesn't that mean that every string must be compared against the full list of ids? What if there are thousands?

Unless I've missed something by only skimming this thread, this is totally unnecessary overhead, easily avoided.

I like the idea of being (optionally) able to specify some given property names that contain ID's that trace back to somewhere in my flows. I just don't want the debug panel processing to gain massive overheads to do it.

[jbudd]

If you click on the node name at the top of a debug message, the editor switches to that tab and flashes the border of the node.

I am not sure what this feature request provides beyond that, but it seems the debug panel message already knows which tab/flow and node sent the message?

If the requirement is to link to a node somewhere else, earlier in the flow maybe, I think predefined field names is much more sensible. Mind you, someone might want an array of these back links...

And provide the feature via a right click menu?

[ralphwetzel]

@TotallyInformation

That has to be run against every string value in every debug output?

No - as already explained.

@TotallyInformation

Unless I've missed something by only skimming this thread, this is totally unnecessary overhead, easily avoided.

Quite a strong argumentation given that you're "only skimming this thread". Feel invited to get presented the details, if you're interested...

[ralphwetzel]

@jbudd

I think predefined field names is much more sensible.

Could you explain that? From what I read in the code base, I got the impression the ids used (e.g. for node and flow ids) are near-to-unique...