-
Notifications
You must be signed in to change notification settings - Fork 23.6k
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
[BUG] Redis Streams XINFO Lag field #13337
Comments
Sure @sundb , I will try. |
@sancar sorry, i realize that the fix in #13338 is totally wrong. |
My tests seem to be all passing now. |
@sancar actually, the root cause is the last id of consume group is before the max deleted id, and the first id of stream is after the max deleted id at the same time. |
I think there are inherent issues with this design. entries_read depends on the value of max_deleted_entry_id, which indicates that entries read is related to the order of xread and xdel. For example, the following example:
The second case will fail. I think this is not in line with expectations. Here, we cannot generate data for lag and entries_read without relying on max_deleted_entry_id. What do you think? @sundb |
@artikell please note the last line in the document:
for stream, he has forgotten |
I understand this issue, but should Redis ensure consistency between entries read and lag. When the lag is invalid, entries read is displayed as valid. This is very confusing. |
Describe the bug
XINFO Lag field is reported wrong in some cases.
To reproduce and expected behavior
Tested against Redis 7.2.4 (d2c8a4b/0) 64 bit with redis-cli 7.2.4 (git:d2c8a4b9)
I will report two different cases
According to documentation at https://redis.io/docs/latest/commands/xinfo-groups/
We have deleted an item between last-delivered-id and the stream's last-generated-id. It should report that lag is not available.
If we continue to read all items in the stream until the end, there seems to be another related problem.
Again according to here:
The lag should be 0. We have read everything there is. There are no undelivered messages that we can read. And following the logic of
lag = entries-added - entries-read
and also docThe counter attempts to reflect the number of entries that the group should have read to get to its current last-delivered-id
, the entries-read should be 4.That is all of course, if I understand the document correctly.
The text was updated successfully, but these errors were encountered: