Repository navigation
bridge: add dlq_config to redis queue plugin - #2705
Open
stackedbyaradhya wants to merge 2 commits into
Open
stackedbyaradhya wants to merge 2 commits into
stackedbyaradhya wants to merge 2 commits into
Conversation
svix-jplatte
left a comment
Member
There was a problem hiding this comment.
Thanks for the PR! I have one minor comment, but otherwise looks good to me.
svix-jbrown
previously approved these changes
Oct 16, 2026
stackedbyaradhya
force-pushed
the
feat/redis-dlq-config
branch
2 times, most recently
from
October 21, 2026 13:13
dc929ab to
058024b
Compare
omniqueue's RedisConfig supports a dlq_config (a queue_key + a max_receives count -- after that many receives, a message is moved to the dead letter queue instead of being redelivered), but the bridge's RedisInputOpts always passed dlq_config: None, so there was no way to configure one. Adds a DeadLetterQueueConfig wrapper (needed since omniqueue's own type doesn't implement Deserialize, following the same wrapper pattern already used for RabbitMQ's BasicConsumeOptions/BasicPublishOptions in this crate) and wires it through in consumer(). Left producer() untouched, matching how it already zeroes out the other consumer-only fields -- a DLQ only makes sense for the receiving side. Added a config-deserialization test (default and explicit value), and a doc'd example in svix-bridge.example.senders.yaml. Verified the test fails without the field wired up, and that the existing redis integration suite still passes unchanged.
jplatte noted serde already treats a missing Option field as None without an explicit #[serde(default)], making the attribute on dlq_config redundant. jbrown's counter (preferring it for explicitness) was dismissed, so removing it per jplatte's original suggestion.
stackedbyaradhya
force-pushed
the
feat/redis-dlq-config
branch
from
October 23, 2026 10:15
78374e7 to
cf1a3b1
Compare
Contributor
Author
|
Any update on this @svix-jplatte @svix-jbrown !? |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #2704
Motivation
omniqueue's RedisConfig supports a dlq_config (a queue_key + a
max_receives count -- after that many receives, a message is moved to
the dead letter queue instead of being redelivered), but the bridge's
RedisInputOpts always passed dlq_config: None, so there was no way to
configure one.
Solution
Adds a DeadLetterQueueConfig wrapper (needed since omniqueue's own
type doesn't implement Deserialize, following the same wrapper
pattern already used for RabbitMQ's
BasicConsumeOptions/BasicPublishOptions in this crate) and wires it
through in consumer(). Left producer() untouched, matching how it
already zeroes out the other consumer-only fields -- a DLQ only makes
sense for the receiving side.
Added a config-deserialization test (default and explicit value), and
a documented example in svix-bridge.example.senders.yaml. Verified the
test fails without the field wired up, and that the existing redis
integration suite still passes unchanged.