Feature Request: Add "Random delay after last message" mode to Delay node

Core Development Feature Requests
1

Feature Request: Add "Random delay after last message" mode to Delay node

What is this idea about

Currently, the Delay node's Rate Limit mode operates with rigid, fixed intervals. For example, if the rate is set to 1 message per 5 seconds, the messages are released at precise, deterministic 5-second increments.

While this is useful for strict throttling, it doesn't allow scenarios where messages need to be passed with randomized delays between each other. Therefore, I would like to propose a new mode: "Random delay after last message".

Proposed Behavior

Instead of a fixed interval T, the interval between the current message and the previous one would be a random value R within a user-defined range [X, Y].

Logic:
Let T{last}_ be the timestamp when the previous message was released.
The next message n will be released at:
Tn = max({arrival_time}, T{last} + {random}(X, Y))

This ensures that messages are neither sent too quickly (respecting the limit) nor sent in a perfectly periodic pattern, introducing much-needed entropy into the flow.

Proposed UI Changes

In the Delay node configuration, when this mode is selected:

  1. Mode Selection: A new option in the dropdown: Random delay from last message.
  2. Configuration Parameter: A numeric input to define the minimum and maximum interval).

Use Cases

  • IoT/Sensor Simulation: Simulating real-world hardware that transmits data at irregular, non-deterministic intervals.
  • Network Traffic Emulation: Testing how downstream services handle non-deterministic message arrival patterns.
  • Load Smoothing / Thundering Herd Prevention: Preventing synchronized "waves" of messages from hitting an API or database simultaneously by introducing jitter, rather then fixed delay.

I tried to search for similar feature request from someone before me. I only found similar issue as #5136 regarding the rigidity of the current rate-limiting implementation, but the discussion in my opinion was a bit off what I am aiming for. I think my solution would not need any heavy memory store but simply the last timestamp of last sent message.

I am happy to implement this and would love to hear the maintainers' thoughts on this approach before proceeding with a Pull Request. Thanks!

2

Why not just use a 2nd delay node after the rate limit node?

image
image1058×336 14.4 KB

3

That is a valid workaround for simply adding some jitter to a flow. As I mentioned, combining a Rate Limit node with a Random Delay node forces a minimum interval (e.g., Trate+random(0,X)T\{rate} + {random}(0, X)Trate​+random(0,X)), which prevents the user from ever achieving an interval smaller than the rate limit.

I see this as a small but meaningful tweak to the functionality already offered by the Delay node. It essentially introduces a distinction between 'delaying every message independently' (the current behavior) and 'delaying the interval between consecutive output messages' (the proposed behavior). Rather than requiring users to manage workarounds to approximate this, I believe implementing it natively within the Delay node would be a much cleaner and more robust solution.

As I said, I'm happy to propose a PR. I just don't want to dive into it without proper discussion.

4

And that adds state to the node ... which isn't a minor change. Adding state to a node which is stateless is a really shame since statelessness is far simpler to handle than maintaining states all the time.

Is there a alternative of creating a custom delay node in a custom package? If the node hasn't yet got any state information, then changing that is something for a custom node package perhaps.

5

Does it not already have state for the mode rate limit with queueing?

6

Me not know, if the state is already there then what I said becomes stateless, i.e. irrelevant.

I was just pointing out that the suggested behaviour would require state for each delay node.

But by the sounds of it, you're right - for rate limiting it will probably already have state.

7

You are absolutely right. The rate limit mode already manages state through its queue and timing mechanisms to ensure messages are released at the correct intervals.

My proposal doesn't aim to introduce a fundamentally new kind of state, but rather a different logic for how that existing timing state is calculated. Instead of using a deterministic, fixed interval for the next release, we would use a stochastic one.

Essentially, we are not adding new complexity to the node's architecture, but simply providing an alternative mathematical rule for the scheduling logic already present in the rate limit implementation. This allows users to achieve jittered arrival patterns without the need for extra nodes or manual workarounds.