Keep showing msg.payload in debug node status even in object mode

Core Development Feature Requests
1

When I've setup a standard debug node to show msg.payload in the status
image

and then I decide I need the full message going to debug panel, it would be very nice to keep showing msg.payload in the node status, to save having to add another debug node just to see it still

image

1 Like
2

the status reflects the property you select... (but no point if you ask for the whole object as it contains too many properties and the first out of the bag may not be useful). If it was fixed to msg.payload then someone would ask why doesn't it show the property asked for etc.

3

I was waiting for this answer :slight_smile:

The feature request "could" snowball but is that a good enough reason to say no? :slight_smile:

I think that in 99.9% of cases - people use debug status to show msg.payload.

But if someone had changed it to show something else, then just carry on showing the something else in that case would be my solution

10

(deleted the off topic posts as they are now in another thread)

1 Like
11

for me.... yes.. I think it is then slightly confusing and would need some sort of docs to explain why it shows payload sometimes but not all the time, and why payload when I have asked for complete message etc - which we don't want.
But let's see what other opinions there are.

12

I have to say that I think it would be really nice to have an optional extra field when the status output is on. Then you could choose something more appropriate for the status such as the topic maybe or some deep property of the payload. I've often thought that would be a nice feature and hopefully not too complex.

Of course, if you wanted to make an even richer feature, making that optional field one where you can use the extended data inputs such as global/flow vars or even JSONata would be amazing.

Also of course, the danger here is that it encourages the use of the Editor for status monitoring which has always been against the stated design principles - though if I'm being honest, I think that horse has long bolted :slight_smile:

Oh, and while we are on the subject of feature requests for the debug node ... would it be possible to add a field to override the default output limit?

From time-to-time you get an output that is chopped off but you don't really want to have to change the settings and restart just for that. Happens if you are trying to extract data from a web page for example.

:grin:

2 Likes
13

THIS IS MY FEATURE REQUEST!!!!!!! :slight_smile:

[edit]go away[/edit] and make your own!!!!!! :slight_smile:

5 Likes
14

I'll knock up a UI for the feature

15

Go on, you know you want mine too :smiling_imp:

16

Julian - you can already use JSONata to pull out what you like in the debug. - and no the horse has not bolted - it may be wandering around confused... but not bolted. And finally - larger debug considerations are indeed another topic.

1 Like
17

... the point is why do we need to change the UI ? adding extra options is generally a bad thing. (but I'm willing to be conviced)

18

So, my original request was to just keep showing msg.payload in status (if it had been selected) when switching to full msg to debug

Basically - just conveniently forgeting to switch it off when switching to full msg to debug :slight_smile:

You mentioned - what happens if person not using msg.payload

I said , well just keep showing that instead

So I think we end up in a situation where what is going to status would need to be showing up on the node UI when in full msg to debug mode

And prob (and it pains me to say this :slight_smile: ) this would make @TotallyInformation request easily achievable as well.

Let me get round to showing a few options so we have something concrete to discuss :slight_smile:

19

The ability to have a status msg on debug that is somewhat independent to the main debug output would be a nice feature.

In this case, I think that the added complexity to the node is easily outweighed by the improved simplicity of flows where you may wish to see a quick status but also see more detail in the debug pane.

At the moment, that would require 2 debug nodes instead of 1 and that has the knock-on effect of causing a deep copy of your msg to be made each time. Or you have to add a function node with a status output - that saves the msg copy but still over-complicates the flow.

1 Like
20

It would be completely dependent... we only send the property of the message asked for to the debug. So this status could only be this or a sub property of this which would be very confusing. We aren't going to start sending the compete message (or try to calculate a superset of two sub properties) for every message "just in case" someone want to see two different parts... the performance would be measurably worse. So no it's not easily outweighed (imho).

Compared to this - @cymplecy ' s request is positively benign !

21

Oh well, worth the discussion anyway. Thanks.

22

That isn't necessarily true. The node status is set on the runtime side, independent of what gets sent back to the Debug sidebar.

So it would be technically possible for the node to show entirely different parts of the message in the sidebar and status.

If anyone wanted to propose some specific UI changes that keeps the Debug node simple to use that would be a useful next step.

1 Like
23

So @cymplecy my 2c worth for when in complete msg mode

image
image932Ă—460 12.7 KB

ie change the label for the status part. (dynamically)

1 Like
24

Forcing the node status to only show msg.payload would be a backward step IMHO.

25

I think @dceejay means that the node status will follow whatever you'd previously set when in default mode (before you changed to to complete msg mode)

1 Like
26

I think I'd stick to the old way of showing complete msg mode but otherwise - super :slight_smile:

image

1 Like