RqueueMessageEnqueuer.enqueueUnique() is misleading

[cbot59]

What's not working?
The method RqueueMessageEnqueuer.enqueueUnique() has similar implementation to enqueue(). At first read I was thinking the behavior of enqueueUnique() is somewhat similar to the message-deduplication guides in which replacing value of the existing messageId. Meanwhile the .enqueue() behavior will reject or discard a new value if the messageId already exist. Am I understanding it correctly or there is something missing related to behavior of both methods?
I was wondering if it's possible to use method from RqueueMessageEnqueuer to support message deduplication scenario without having to register a MessageProcessor to the SimpleRqueueListenerContainerFactory considering this is a common usage scenario

A clear and concise description of what the bug is.

What're application dependencies ?

• Rqueue Version: 2.13.2-RELEASE
• Spring Boot Version: 2.7.18
• Spring Messaging Version: -
• Spring Data Redis Version: 2.7.18
• Any other spring library dependencies and their version

How to Reproduce (optional)?

• Steps to reproduce the behaviour
• A sample reproducible code if possible.

Additional Details (optional)

Add any other context about the problem that would be helpful like OS, Redis, Docker etc
Redis: 5.1.13

[sonus21]

Hi @cbot59
Thanks for flagging this issue, internally it will reject the message at the time of consumption, though there's been improvement in this area, if you're using latest spring boot version, upgrade to latest version 3.4.0. see this discussion for other detail #259.

Though it appears that it does not do anything but when we consume the message it will check the existing message with id, if it finds that the message is already processed it will discard.

[cbot59]

I think we have different definition of unique @sonus21 As per my understanding, your definition of unique behaves similar to "at-most-once" once the message is COMPLETED

Given my use case, a queue named messages had a message with messageId = 1 and enqueuAt() to be executed later e.g. 5PM. During queue period, the same messageId are re-enqueueAt() to be executed later e.g. 6PM.
What's the expectation here? Does the 6PM message will be discarded or the 5PM message will be replaced? If it's discarded, what's the preferred way in order to replace the old message with new one?

[sonus21]

You're right, the version you're using follows at-most once strategy though in the latest version this has been fixed. Now it will throw error at the time of enqueue.

[cbot59]

how about my use case, what's the preferred way to do it? given enqueueUnique() unable to support my scenario as it will rejects the same messageId

[sonus21]

The easiest way to make a similar patch to 2.x branch. I'm happy to consider any PR from you if you can raise a pr against branch 2.x.

2nd best option to use middleware to reject the message.

[cbot59]

Mind your review @sonus21 #274

Actually what I want is not rejecting the message, instead overwrite the existing messageId execution time to newer value

[sonus21]

This might have been working out of the box, did you try this scenarios?

[cbot59]

@sonus21 It turns out my use case supported of of the box

Here's my observations on a message with same messageId

• If we want to renew schedule/execution time value, use enqueueIn() or enqueueAt() is sufficient
• If we want to avoid new schedule/execution time value, use enqueueUniqueIn() is required

[sonus21]

That’s what I remember when you said you want to override the data. Thanks, Sonu Kumar Linkedin <https://in.linkedin.com/in/sonus21> GitHub <https://github.com/sonus21>

…

On Fri, 31 Oct 2025 at 2:55 PM, Rivaldi ***@***.***> wrote: *cbot59* left a comment (sonus21/rqueue#270) <#270 (comment)> @sonus21 <https://github.com/sonus21> It turns out my use case supported of of the box Here's my observations on a message with same messageId - If we want to renew schedule/execution time value, use enqueueIn() or enqueueAt() is sufficient - If we want to avoid new schedule/execution time value, use enqueueUniqueIn() is required — Reply to this email directly, view it on GitHub <#270 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC2FCPXR35KNPHPPOLYFPJT32MTKLAVCNFSM6AAAAACKQKVIGSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTINZSGA4TANZSGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>