Weird issue with node-red-contrib-queue-gate

General
21

I beg to differ. Even if it were cloned when stored then the cloned message sent would be corrupted after being sent, leaving the corrupted clone in the queue.

22

You may both be right :smiley:. @dceejay's suggestion, clone messages before putting them in the queue, would solve the problem. @Colin points out that the peek command is the immediate cause of the issue, because it turns loose a copy (not a clone) of a message that can then be changed, corrupting the contents of the queue. Certainly, cloning the "peeked" message before sending it would cure that. Which approach to take depends on whether there are other ways to modify messages already in the queue. So far, I have not found a way to do it using only core nodes, and I suspect (hope) that they and the runtime are constructed so that it cannot happen. Still, contributed nodes (for example, mine) could behave badly, so @dceejay's approach may be the safe one.

Unless someone has a better idea, I may do a bit of both. First, have the peek command clone the message it sends. Second, clone the queued messages, with an option to turn off that cloning (on by default) if the user has memory or performance issues.

23

It wouldn't solve the problem demonstrated by the test flow I posted. I am not sure whether you meant that it would solve that problem. It might solve a different set of problems though.

24

You're right, of course. I wasn't thinking clearly. Unless the "peeked" message is a clone, it will still be identical to whatever is in the queue. A fix is on the way.

25

Version 1.5.1 is available and should fix this issue.

1 Like
26

That fixes my peek issue, thanks.
Did you decide to clone on the way in and also for peek on the way out?

27

No, I'm waiting to see whether not cloning really can cause issues. Have you run into any cases? I have not so far.

28

No, in fact I can't think of a case where it is necessary to clone on the way in.

29

I agree. So, I'm inclined to leave it as is until something comes along to change my mind.

30

Perhaps @dceejay can suggest a problematic use case where cloning is necessary other than in the 'peek' case.

1 Like
31

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