# \[ANNOUNCE\] node-red-contrib-queue-gate

**URL:** <https://discourse.nodered.org/t/announce-node-red-contrib-queue-gate/3948>\
**Category:** Share Your Nodes\
**Created:** [13 October 2018 02:28 UTC](https://discourse.nodered.org/t/announce-node-red-contrib-queue-gate/3948 "2018-10-13T02:28:16Z")\
**Posts on this page:** 8\
**Page:** 2

<div class="post-metadata">

**Author:** ![drmibell](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/drmibell/32/8424_2.png) [@drmibell](https://discourse.nodered.org/u/drmibell)\
**Post date:** [29 July 2019 19:52 UTC](https://discourse.nodered.org/t/announce-node-red-contrib-queue-gate/3948/22 "2019-07-29T19:52:35Z")

</div>

> [@dceejay](#):
>
> I would say reset/dropped

That would be my first choice, too. The trouble with a sequence of commands is that I haven't found one that would do the toggle (reverse things when repeated). It might not be hard to make flush vs reset a user option, just tricky to make clear what it all means.

---

<div class="post-metadata">

**Author:** ![dceejay](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/dceejay/32/38_2.png) [@dceejay](https://discourse.nodered.org/u/dceejay)\
**Post date:** [29 July 2019 19:57 UTC](https://discourse.nodered.org/t/announce-node-red-contrib-queue-gate/3948/23 "2019-07-29T19:57:10Z")

</div>

I thought the toggle options being proposed were open/closed and open/queuing which would necessitate a deploy (and thus reset) in between. To go queuing to closed would only be via a “special” msg , in which case doing a sequence wouldn’t be much harder.

---

<div class="post-metadata">

**Author:** ![drmibell](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/drmibell/32/8424_2.png) [@drmibell](https://discourse.nodered.org/u/drmibell)\
**Post date:** [29 July 2019 20:44 UTC](https://discourse.nodered.org/t/announce-node-red-contrib-queue-gate/3948/24 "2019-07-29T20:44:40Z")

</div>

> [@dceejay](#):
>
> the toggle options being proposed

I can't guarantee clarity, but here goes. The toggle command between `open` and `closed` already exists. (See the `toggleCmd` payload in the documentation.) I think what @cymplecy would like is a new control payload (perhaps `qtoggleCmd`) that would toggle the gate between `open` and `queueing` in a similar way. Presumably, that command would have no effect on the gate if it is `closed`.

---

<div class="post-metadata">

**Author:** ![cymplecy](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/cymplecy/32/2773_2.png) [@cymplecy](https://discourse.nodered.org/u/cymplecy)\
**Post date:** [31 July 2019 14:36 UTC](https://discourse.nodered.org/t/announce-node-red-contrib-queue-gate/3948/25 "2019-07-31T14:36:33Z")

</div>

Just to see if I could, I've made some mods to add a toggle action option  
Seems to work OK on my machine  
Done a pull-request from my fork

---

<div class="post-metadata">

**Author:** ![drmibell](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/drmibell/32/8424_2.png) [@drmibell](https://discourse.nodered.org/u/drmibell)\
**Post date:** [31 July 2019 23:53 UTC](https://discourse.nodered.org/t/announce-node-red-contrib-queue-gate/3948/26 "2019-07-31T23:53:07Z")

</div>

Thanks. I'll take a look.

---

<div class="post-metadata">

**Author:** ![cymplecy](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/cymplecy/32/2773_2.png) [@cymplecy](https://discourse.nodered.org/u/cymplecy)\
**Post date:** [5 November 2019 11:24 UTC](https://discourse.nodered.org/t/announce-node-red-contrib-queue-gate/3948/27 "2019-11-05T11:24:46Z")

</div>

> [@drmibell](#):
>
> Presumably, that command would have no effect on the gate if it is `closed` .

I've discovered an edge-case issue with this philosophy 🙂  
Assuming that restore from saved state is in use...

1. If gate in open/close mode and actually closed:  
Then if you configure it to open/queued mode and deploy - you can't control the gate with just a toggle command.  
It will stay closed  
I propose that in this case, a received toggle command should switch the gate to queued (as likely to cause least disruption to any messages arriving)  
Then next toggle would cause gate to goto open mode as usual

2. Same happens if gate in open/queued mode and actually closed:  
The gate will stay closed on a toggle command  
I propose that in this case, a received toggle command should switch the gate to queued (as likely to cause least disruption to any messages arriving)  
Then next toggle would cause gate to go to open mode as usual

I've done code changes to implement this so will do a PR if your happy to proceed

---

<div class="post-metadata">

**Author:** ![drmibell](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/drmibell/32/8424_2.png) [@drmibell](https://discourse.nodered.org/u/drmibell)\
**Post date:** [5 November 2019 19:48 UTC](https://discourse.nodered.org/t/announce-node-red-contrib-queue-gate/3948/28 "2019-11-05T19:48:07Z")

</div>

Interesting... I would not call this an edge case, since the node has actually had this behavior from the beginning. If you create a new instance and set the `Default State` to `queueing` without making any other changes in the node edit dialog, the node will not respond to `toggle` commands. This is as designed and seems not to have caused any issues in the past. The recent introduction of the alternative `toggle` definition merely changes the unresponsive state from `queueing` to `closed` when that option is selected.

If I understand your proposal correctly, you want the `toggle` command to force the node out of the unresponsive state. If that state is `closed`, it would go to `queueing`. If it is `queueing`, the safest option would presumably be `closed`. The choice of which state to enter in these cases is somewhat arbitrary and might not be obvious to the user.

I am not clear how the current behavior becomes a problem for the user. There are only two ways that the node can enter the unresponsive state. One is if that state is the `Default State`, and the other is if it is entered via a control message. In the first case, the node can be made responsive by selecting one of the other two states as the `Default State`. In the other case, the user presumably wants the node to be in the unresponsive state and restored to it if persistent context is used. The flow could easily be designed so that response to the `toggle` command could be restored when needed.

If I am missing something here, or there is an important use case that would be enabled by this change, I would be happy to continue the discussion.

---

<div class="post-metadata">

**Author:** ![cymplecy](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/cymplecy/32/2773_2.png) [@cymplecy](https://discourse.nodered.org/u/cymplecy)\
**Post date:** [5 November 2019 21:28 UTC](https://discourse.nodered.org/t/announce-node-red-contrib-queue-gate/3948/29 "2019-11-05T21:28:44Z")

</div>

1 I did say it was an edge case 🙂  
2. I only setup my gates with a toggle inject so if it doesn't respond to the toggle I have to go back into the node config  
3. It happened to me in real life 🙂 So I investigated it and came up with solution to avoid in future

Did I mention it was an edge case? 🙂

[Previous page](https://discourse.nodered.org/t/announce-node-red-contrib-queue-gate/3948.md?page=1)