Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What does XGROUP SETID do to the PEL and re-processing of messages? #5763

Open
johntmyers opened this issue Jan 9, 2019 · 2 comments
Open

Comments

@johntmyers
Copy link

The functionality described for XGROUP SETID mentions:

Finally it possible to set the next message to deliver using the SETID subcommand. Normally the next ID is set when the consumer is created, as the last argument of XGROUP CREATE. However using this form the next ID can be modified later without deleting and creating the consumer group again. For instance if you want the consumers in a consumer group to re-process all the messages in a stream, you may want to set its next ID to 0.

How does this affect existing consumers and already ACK'd messages? If SETID sets the ID to 0, some of the messages in the stream may have already been ACK'd (or never added to a PEL) and some may still be on the PEL for some consumers.

XGROUPREAD has this note about using IDs that are explicit: "If the ID is any other valid numerical ID, then the command will let us access our history of pending messages. That is, the set of messages that were delivered to this specified consumer (identified by the provided name), and never acknowledged so far with XACK."

Does resetting the last ID actually allow consumers to re-consume messages that were XACK'd?

@johntmyers
Copy link
Author

johntmyers commented Jan 9, 2019

Ok so I was able to test it. It appears that if you SETID back to 0, all things in the PEL remain until a consumer executes a XREADGROUP with > and reads a message that was in another consumer's PEL.

So let's say you have stream S, and you ADD foo, foo2, foo3 to it. You create consumer group G, and consumer A reads all three messages. A's PEL now has foo, foo2, foo3.

If you SETID back to 0. Then create consumer B, and read > with a count of 1. That will transfer foo from A to B, and reset foo's counters.

@leomurillo
Copy link
Contributor

Sounds like a bug to me.

If SETID is intended to reprocess the stream on this group, PEL should reflect it. Otherwise, PEL has garbage information that may cause duplicate processing of messages left on PEL and false trigger of recovery procedures.

The doc should mention PEL must be manually cleared, using XACKs I guess, if this what we are supposed to do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants