The problem/use-case that the feature addresses
I've heard of use cases where the producer entity may use a retry mechanism when XADDing an entry but would like to avoid adding the entry in case it was already added in a previous attempt.
Of course, the message ID (streamID) is a unique identifier, but it might prove problematic because of its monotonicity (consider several independent producers).
Description of the feature
I don't have any good ideas regarding the solution itself, and, to be honest, I'm not entirely sure it deserves a server-side solution, I could argue that lists have the same "problem"
Alternatives you've considered
It is possible to use Lua and another helper hash to map between a client-generated unique ID and the streamID (or vice versa) returned by XADD, but how do you remove stale elements from this hash? with XDEL it's easy because you know exactly the stream entry that is deleted, but with XTRM it becomes O(n)
Comment From: madolson
I have also seen this but I don't have a great answer either. 95% of the time I've talked with users about this, they solve this with idempotency of the messages, so that the message can be handled multiple times by the consumers. Some people deduplicate them independently with a cache on either end in the application layer above Redis, but that is forcing end users to do a bunch of work.