Dynamically creating widgets with payload in same msg - payload is not always reflected

Dashboard
1

Hi - I face a strange issue . And this is seen on multiple widgets - forms / dropdown etc.

  1. I configure multiple widgets (forms etc) using dynamically msg.ui_update
  2. In the same message i also add the payload to msg.payload.

Expectation : Widget would be configured and the payload would be shown.
Actual : While the widget gets dynamically defined - sometimes the payload sent is not reflected. The widgets continues to show earlier payload (probably its stored internally) or nothing.
(The behavior is inconsistent and not always reproducible - but very often seen)

To overcome this - i need to send the same msg to widget a second time with the delay. So i have a flow with bunch of such widgets and delay nodes to handle the above issues.

See the snapshot of a simplistic flow. My flows have 30-40 widgets.

This leads to Maintainance issues, unnecessary nodes leading to heavier flows.
Plus due to the delay sometimes the user experience gets impacted as he sees payload on screen and with delay it changes to new payload.

image
image1153×197 12.8 KB

2

this might suggest that the downstream functions are modifying the message before it reaches the target. By adding a trigger to resent it, you have created a scenario where two wires leave a node and due to underlying rules in the core, any msg that leaves a node and has to travel more than 1 parallel wire, every messages gets cloned (details are hazy, the first might not, but all others do). The side effect is that the cloned message cannot be referentially modified by downstream/upstream changes.

Try this:

  1. delete the delay nodes
  2. clone the msg at the start of each function and return the clone
const m = RED.util.cloneMessage(msg)
...
m.whatever = "new value"
...
return m
3

On second thoughts, this might be a timing thing. It might be a dashboard issue. It may even the way it has to be - in which case we will document it.

Would you prepare a reproducible flow with and without the extra delay please?

4

Thanks @Steve-Mcl .

Not fully clear what you suggest. I do this only for db2 widgets as target. Plus all my db2 widgets are "non passthrough". So unless user clicks the widget - msg cannot go to next node. I would assume that when the widget gets 2 msgs with same client - the last one prevails.

Thanks. But delay may be needed. My observation is unless i add some delay - race condition occurs and its not guaranteed that that the ui_update reaches before payload. My intent here is to not have these delay nodes or even cloned messages (it still means multiple messages passing through the system ) and be able to pass both msg.ui_update and msg.payload in same message. This is obviously, unless we document (even post this) - that for dynamically configured widgets - msg.ui_update and msg.payload should be on different successive messages.

This is my guess as well. Or how the node ingests a message. My view if the msg has both ui_update and payload - ui_update processing should be done and only once done payload attached to the widget .

I will try. I dont see this behavior always. But have seen it very often to eventually realize this issue and add delay nodes to my entire flow. So having a reproducible flow may become tricky. But will give it a shot. Will come back.

5

Is not the fundamental problem that you are seeing the fact that sometimes when a message includes both payload and ui_update that the payload is not acted upon?

Edit: If so then can you post a simple example that shows the problem?

6

The key word is "sometimes" :smile: .
I hope what i post can reproduce the issues often enough. Lets see. Will try to post it today.

7

Were you able to replicate the issue?

8

Unable to create a reproducible flow :frowning: .
I see it happening in my flows though.

If something comes will open the thread again.

9

Ok. I think i managed to play with it - and "somewhat" understand the situation.

  1. I am using most of my groups as displayed/shown via. ui-control.

  2. The issue seems to be a race condition.

  3. I have part of the flow (lets say part 1) to inject msg.payload to UI Control to display the group.

  4. I have part of the flow (lets say part 2) running in parallel. It prepares. msg.payload and msg.ui_update (for widget definition) and injects to widget (sitting on that group)

  5. Depending on which part of the flow gets executed first - i see /dont see the issue.

  6. If part 1 to display ui_control gets executed first then its all good. part 2 gets executed with delay and shows data on the widget.

  7. If part 2 (data prep + widget creation) gets executed first , and then part 1 to display widget gets executed - the data doesnt get displayed.

My guess is when we display a group via. ui control - it discards the data on the widget.

I am still playing to understand if indeed this is the situation for all my flows. So more may come.