# Rate limiting based on exec node completion
**URL:** https://discourse.nodered.org/t/rate-limiting-based-on-exec-node-completion/53115
**Category:** General
**Created:** [2 November 2021 09:39 UTC](https://discourse.nodered.org/t/rate-limiting-based-on-exec-node-completion/53115 "2021-11-02T09:39:45Z")
**Posts on this page:** 20
**Page:** 2
### Author:  [@cymplecy](https://discourse.nodered.org/u/cymplecy)
#### Post date: [3 November 2021 08:11 UTC](https://discourse.nodered.org/t/rate-limiting-based-on-exec-node-completion/53115/21 "2021-11-03T08:11:38Z")
> [@dceejay](#):
>
> if that is the ONLY property then the delay node will not send it on
Aah - I'll eventually get to know everything about the delay node 🙂 🙂
I'll give that a go and see where I get with it
---
### Author:  [@Colin](https://discourse.nodered.org/u/Colin)
#### Post date: [3 November 2021 08:12 UTC](https://discourse.nodered.org/t/rate-limiting-based-on-exec-node-completion/53115/22 "2021-11-03T08:12:13Z")
Another approach that does work in the simple case of 'only one message at a time in the flow' is to use a pair of node-red-contrib-semaphore nodes around the flow. Arguably that is simpler, particularly if you don't need to retain messages in the queue over a restart.
---
### Author:  [@cymplecy](https://discourse.nodered.org/u/cymplecy)
#### Post date: [3 November 2021 08:13 UTC](https://discourse.nodered.org/t/rate-limiting-based-on-exec-node-completion/53115/23 "2021-11-03T08:13:44Z")
> [@dceejay](#):
>
> (Or use a function node to create a "clean" msg with only msg.flush=1 .
Maybe we could have a delete all exisiting properties option in the change node instead of having to do this?
I'm always wanting to do stuff without resorting to function nodes 🙂
---
### Author:  [@dceejay](https://discourse.nodered.org/u/dceejay)
#### Post date: [3 November 2021 08:14 UTC](https://discourse.nodered.org/t/rate-limiting-based-on-exec-node-completion/53115/24 "2021-11-03T08:14:17Z")
Well in normal flush mode you may just want to add the msg.flush = true to flush out all the messages including the one currently being sent. (with all it's properties)
---
### Author:  [@cymplecy](https://discourse.nodered.org/u/cymplecy)
#### Post date: [3 November 2021 08:26 UTC](https://discourse.nodered.org/t/rate-limiting-based-on-exec-node-completion/53115/25 "2021-11-03T08:26:51Z")
Deleting all msg properties and just sending a msg.flush=1 seems to do the job 🙂
All we need for a core-node only solution is something to delete all message properties.....
---
### Author:  [@dceejay](https://discourse.nodered.org/u/dceejay)
#### Post date: [3 November 2021 08:37 UTC](https://discourse.nodered.org/t/rate-limiting-based-on-exec-node-completion/53115/26 "2021-11-03T08:37:18Z")
I think an option to add a create blank object or remove all properties or ( insert better name here) option on the change node is worth a discussion
---
### Author:  [@zenofmud](https://discourse.nodered.org/u/zenofmud)
#### Post date: [3 November 2021 08:41 UTC](https://discourse.nodered.org/t/rate-limiting-based-on-exec-node-completion/53115/27 "2021-11-03T08:41:28Z")
> [@dceejay](#):
>
> ( insert better name here)
"clear object"
---
### Author:  [@Colin](https://discourse.nodered.org/u/Colin)
#### Post date: [3 November 2021 09:01 UTC](https://discourse.nodered.org/t/rate-limiting-based-on-exec-node-completion/53115/35 "2021-11-03T09:01:03Z")
If you get a working flow using core nodes (or the q-gate node) could you post it here so I can try it please. For testing I suggest removing the exec node and the pico node and just using a fixed delay as the process to run, then we can all try it.
---
### Author:  [@cymplecy](https://discourse.nodered.org/u/cymplecy)
#### Post date: [3 November 2021 09:03 UTC](https://discourse.nodered.org/t/rate-limiting-based-on-exec-node-completion/53115/36 "2021-11-03T09:03:08Z")
See @dceejay example flow for that
---
### Author:  [@cymplecy](https://discourse.nodered.org/u/cymplecy)
#### Post date: [3 November 2021 09:22 UTC](https://discourse.nodered.org/t/rate-limiting-based-on-exec-node-completion/53115/37 "2021-11-03T09:22:31Z")
JFI This is my current working flow
The change node has 5 rules since I'm processing incoming MQTT messages, so it needs to delete quite a few msg properties and then set msg.flush to 1 before feeding it back into the delay node
It seems to be working fine for the past 30 mins
---
### Author:  [@Colin](https://discourse.nodered.org/u/Colin)
#### Post date: [3 November 2021 12:26 UTC](https://discourse.nodered.org/t/rate-limiting-based-on-exec-node-completion/53115/38 "2021-11-03T12:26:35Z")
Yes, ok, that principle does work, if you can specify a maximum time that the message processing will take. Which likely you can in this case.
---
### Author:  [@dceejay](https://discourse.nodered.org/u/dceejay)
#### Post date: [3 November 2021 14:08 UTC](https://discourse.nodered.org/t/rate-limiting-based-on-exec-node-completion/53115/39 "2021-11-03T14:08:01Z")
well you can use the maximum time as the safety valve/timeout - in this case you could set it to some really large number as you should always get a feedback message to release the next message.
---
### Author:  [@Colin](https://discourse.nodered.org/u/Colin)
#### Post date: [3 November 2021 14:46 UTC](https://discourse.nodered.org/t/rate-limiting-based-on-exec-node-completion/53115/40 "2021-11-03T14:46:24Z")
It is important to make sure that the delay time is noticeably greater than the message processing time can ever be, otherwise the flow can fail. Consider the case where there are two queued messages, with a rate of 1 per 20 seconds specified. If the process takes exactly 20 seconds then the nodes that will send the `flush` message get started. However, before the flush gets back to the delay node it will release the next message, then when the flush arrives it will send another message immediately, so two messages will have been sent together.
---
### Author:  [@dceejay](https://discourse.nodered.org/u/dceejay)
#### Post date: [3 November 2021 15:25 UTC](https://discourse.nodered.org/t/rate-limiting-based-on-exec-node-completion/53115/41 "2021-11-03T15:25:50Z")
err no they won't - the flush (being blank (see other discussions)) - doesn't send it's own message - so if there is a message waiting it releases it. if not it doesn't send anything (until next message arrives)
---
### Author:  [@Colin](https://discourse.nodered.org/u/Colin)
#### Post date: [3 November 2021 15:50 UTC](https://discourse.nodered.org/t/rate-limiting-based-on-exec-node-completion/53115/42 "2021-11-03T15:50:20Z")
> [@Colin](#):
>
> Consider the case where there are two queued messages,
I was not clear enough. I meant one being processed _and_ two in the queue. Then the sequence is as follows:
Just before 20 seconds the message being processed completes and sends it message to (in @cymplecy's flow) the 'Change 5 rules' node
At 20 seconds (the flush has not got through the Change node yet) the Delay node releases its next message.
A fraction of a second later the flush gets emitted by the Change node and into the Delay node, which releases the next message.
---
### Author:  [@dceejay](https://discourse.nodered.org/u/dceejay)
#### Post date: [3 November 2021 16:01 UTC](https://discourse.nodered.org/t/rate-limiting-based-on-exec-node-completion/53115/43 "2021-11-03T16:01:19Z")
ah right - yes - hence why I said you need to set the timeout to a really large number (that would never happen in normal circumstance - eg minutes or hours)
---
### Author:  [@Colin](https://discourse.nodered.org/u/Colin)
#### Post date: [3 November 2021 16:16 UTC](https://discourse.nodered.org/t/rate-limiting-based-on-exec-node-completion/53115/44 "2021-11-03T16:16:26Z")
I don't think that flow extends to the case where the message needs to be re-tried after a timeout in the case of a failure does it?
---
### Author:  [@cymplecy](https://discourse.nodered.org/u/cymplecy)
#### Post date: [3 November 2021 16:17 UTC](https://discourse.nodered.org/t/rate-limiting-based-on-exec-node-completion/53115/45 "2021-11-03T16:17:19Z")
I think we are mis-using the delay node (in rate limiter mode) for this application but in practice its very good with an easily user definable timeout if things go wrong upstream for any reason.
@colin - just noticed that you posted while I'm typing this but will press reply on this one anyway
---
### Author:  [@cymplecy](https://discourse.nodered.org/u/cymplecy)
#### Post date: [3 November 2021 16:19 UTC](https://discourse.nodered.org/t/rate-limiting-based-on-exec-node-completion/53115/46 "2021-11-03T16:19:38Z")
There isn't a requirement for a retry - it's a QOS 0 type philosophy just designed not to overrun processes that take some time to complete
Your flow/node does that very well when certainty is required
---
### Author:  [@Colin](https://discourse.nodered.org/u/Colin)
#### Post date: [3 November 2021 16:48 UTC](https://discourse.nodered.org/t/rate-limiting-based-on-exec-node-completion/53115/47 "2021-11-03T16:48:27Z")
> [@cymplecy](#):
>
> There isn't a requirement for a retry
Yes, I know, I was just wondering whether there is a similar way, using core nodes, to slove the more general problem.
[Previous page](https://discourse.nodered.org/t/rate-limiting-based-on-exec-node-completion/53115.md?page=1)
[Next page](https://discourse.nodered.org/t/rate-limiting-based-on-exec-node-completion/53115.md?page=3)