Feature request: message delivery pending

#1

Not sure if demand is there, but I'd like to request some sort of visual indicator (perhaps a colored border indicator like the debug node gets if you hover over one of its messages in the debug window) to let users know if a node on the canvas is currently processing a message. This would make it easier to determine whether a lack of output is a result of a flow with no actual output, or whether we're just being impatient waiting for a particularly taxing message.

0 Likes

#2

We’re not going to do this for most nodes as the comma overhead really does build up if you have lots of nodes and a very high message rate.

Some nodes like the http request node and exec node do show an indicator while processing.

Which particular node(s) are you thinking sbout

0 Likes

#3

The ones in particular that I was using where this came to mind was a CSV>split>switch>join chain. Before I thought better of it, I was feeding it a way too large CSV file (the resulting filtered array contains around 400,000 objects, each with 4 properties.) I cut it to something a little more manageable for prototyping (the only time any visual indicator would be a valid ask, because I have drank and fully digested the "the editor is not a dashboard" kool-aid) but it still made my brain itch in a very "I wonder if anyone else would have use for that too" sort of way.

That all said, I don't know enough about what's going on under the hood to know if it's a reasonable suggestion or something totally infeasible.

1 Like

#4

Please note that I mean the following not seriously:

One way to solve this would be the following:
You have a button somewhere to enable "process" indicators on a flow tab basis.
Then on this flow only every wire would flash in a color if a message is passed through.

It would definitely look cool :slight_smile:

If it is turned off, no performance impact

0 Likes

#5

For csv - you can use the file in node and set it to send a msg per line. This effectively reads the file as a stream and does a split (and adds the relevant msg.parts) - so it doesn't have to wait to load the complete file.

0 Likes

#6

Maybe cool - once. There was a reason the <blink> tag was deprecated. Having lived through it once I don't need to go there again.

1 Like

#7

Not a bad idea. I was trying to keep it whole on the way through so I could use an array reverse at one point (working with a log from a medical device that dumps its audit logs in what feels to be the least useful formatting imaginable for our purposes, but derp, I can just reverse the final array after the join.)

I guess my mental image was more of an "amber outline if there are any messages pending" approach.

0 Likes

#8

After the file in the necessary msg.parts are in place so you should be able to use a join again at some point - maybe after having reduced some fo the fields, - and then yes reverse the array later.

There once was a fork that did flash the wires... (anyone remember Octoblu :wink: ) and we didn't accept the PR then either...

0 Likes

#9

Yep, that's what I ended up doing.

That sounds awful...

0 Likes

#10

I probably shoudn't have posted my post, since I really did not meant it seriously, sorry :slight_smile:

0 Likes

#11

Sometimes knowing or talking about what doesn't work is as important as knowing or talking about what does.

0 Likes

#12

well it did look fine when really slow - but we don't want slow :slight_smile:

0 Likes

#13

Aww, that would have been way cool! I think that animated rainbow colours would be fab. :nerd_face::exploding_head:

0 Likes

#14

You can get back in your box with Timothy Leary ! :sunglasses:

1 Like