It is a pity that sending {flush: 1, reset: true} to the Delay node does not flush and then reset. It appears to reset first, so there is nothing to flush.
The reason this was not implemented in the first place was that originally flush was just boolean - all or nothing - so in the case of a flush you always ended up empty anyway... now that we accept flushing a specified number of messages then indeed flushing that many, then reseting does make sense.
However there are some possible extra wrinkles that could be considered.
if flush and reset are both specified should the timer be honoured for that flushed message ? IE the flushed message would get sent immediately (as that is what flush means), but any subsequent arrivals would not get sent after the time out - .... a stand alone reset would still cancel all timers so the next message would go immediately.
The original thread was about how to always send the last message to arrive (as well as the first) - but still honour the rate limit. There are several ways the delay node could be enhanced to do this
a) Add a max queue depth option (which in that scenario could be set to 1
b) Add a specific "and always send last msg" option
c) Allow msg.flush to accept -ve number to flush last to arrive rather than first (which if combined with reset as per 1 above would have desired effect.
d) others tdb
So this thread is discuss if this is a good thing (sounds good to me) - and if it would likely break anyone if implemented. Thoughts please !
I think yes, the timer should be honoured, though that does mean it is not the same as a flush followed by reset. That means that it is really a Clear rather than a Reset. Intuitively I think that is what a user would expect.
For item 2, I don't like the -ve flush suggestion. It is too difficult to understand.
For simplicity the 'send last message' suggestion appeals, but on the other hand a max queue depth may be useful for users who want to queue messages, but want a safety net to prevent the queue growing too large in unusual or fault conditions.
On whether the suggestions would break existing flows then item 2 should not break anything as it does not change existing behaviour, as far as I can see. Item 1 could theoretically break a flow if anyone is asking for flush and reset but didn't actually want the flush, which seems a rather unlikely situation. Arguably this change could be considered a bug fix, in the sense that currently flush+reset does not flush.
Personally, I just want the first received msg to be passed and then start the delay in rate limit mode. I rarely use the Delay node because it doesn't do this.
Think of it like windshield wipers in intermittent mode...when you turn it on you want a wipe before the delay, right? OK, maybe that's lame but it does mostly illustrate my point.
The flush & reset don't matter to me, at least not yet.
So do you mean that the current node fulfills what you want? That is the case for most users, we are discussing here a possible enhancement here that should not affect existing uses.
Edit Or do you mean the you want a node that automatically repeats an input at a defined rate, once you trigger it? In which case the Trigger node will do that for you.
Change 'For each msg.topic` to 'Every message' (or whatever it is, something like that). If you still can't make it work then please start a new thread and ask there, so as not to take this thread off topic. Thanks.
@LosinIt, sorry, perhaps I misunderstand what you are saying. Are you saying that you do want item 1 but don't need item 2? If so then unfortunately item 1 won't address your problem as the proposal will not affect 'For each msg.topic` mode. If you don't need msg.topic mode then change that and see whether the standard node does what you want.
Currently the two modes are slightly different... in All messages mode the timer does indeed start with the first message - and clear itself if the queue is empty (and then the next message will start it again).
In each msg.topic mode the timer is just started and runs continuously so the spacing is more guaranteed. The thinking being that if you are asking it to handle multiple topics then you are probably expecting more than one to arrive - so you may as well wait so you can build up the package before sending all (or picking one).
You can maybe cheat it by allowing msg.rate to be overridden and always sending that as well as doing that will clear the existing timer and restart a new one.
The suggestions above are not intending to change these behaviours at all.
Sorry, I should not have posted here at all and I think your suggestion may well take care of my concern. Please disregard any implications regarding the subjects of this topic.
