feat(new transform): add a simple delay transform#25407
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c81015ff6f
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
pront
left a comment
There was a problem hiding this comment.
One idea worth considering is adding a VRL condition for each event in order to answer "do i want to forward this event now?". We could also add retries + exponential backoff. Non-blocking but something worth considering.
thomasqueirozb
left a comment
There was a problem hiding this comment.
Hi @esensar. Thanks for this! I thought about implementing this myself a couple of times before.
This is missing website/cue/reference/components/transforms/delay.cue and website/content/en/docs/reference/configuration/transforms/delay.md
That sounds good. This is probably too simple the way it is (even though it could probably be combined with other components to achieve some of these things). I am not sure about retries though. What would we be retrying here? |
Co-authored-by: Thomas <thomasqueirozb@gmail.com>
I just ran |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7d93ced0b2
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
@esensar some condition until it is evaluates to true and the event can be forwarded |
Oh, alright, that is interesting. I will see about adding that in too. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: cc922cb2ff
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
What do we do if it never evaluates to true? Or do we just leave that to the user to ensure? (with some warning probably) |
I just realized that the static condition that I added is not useful at all, since that functionality can be provided by filter transform before the delay transform, while that delay until some condition is met can be more useful. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 03c62f57fa
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| while capacity.get() <= self.queue.len() && let Some(next) = self.queue.next().await { | ||
| yield next.into_inner(); |
There was a problem hiding this comment.
Apply delay condition when unblocking a full queue
When queue_capacity is set and the default overflow_strategy = "block" is used, this path drains an expired queued event directly to the output to make room for the new event. That bypasses the delay_until_condition.check(...) logic used in the normal queue-expiry branch, so a queued event is emitted as soon as its first delay expires even if delay_until_condition is still false whenever the queue is full and another input event arrives.
Useful? React with 👍 / 👎.
Summary
Adds a new transform which delays each event in the pipeline by a fixed duration.
Vector configuration
How did you test this PR?
Ran the included test and ran Vector with the above configuration to confirm that events were correctly delayed.
Change Type
Is this a breaking change?
Does this PR include user facing changes?
no-changeloglabel to this PR.References
Notes
@vectordotdev/vectorto reach out to us regarding this PR.pre-pushhook, please see this template.make fmtmake check-clippy(if there are failures it's possible some of them can be fixed withmake clippy-fix)make testgit merge origin masterandgit push.Cargo.lock), pleaserun
make build-licensesto regenerate the license inventory and commit the changes (if any). More details on the dd-rust-license-tool.