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

feat(streams): support entries_read and lag for XINFO GROUPS #1952

Merged
merged 3 commits into from Sep 28, 2023

Conversation

theyueli
Copy link
Contributor

@theyueli theyueli commented Sep 27, 2023

entries_read and lag have been added to the output of XINFO GROUPS since Redis 7.0. Also fixed a bug that incorrectly sets the initial value of entries_read when a consumer group is created.

fixes #1948

So now it prints:

127.0.0.1:6379> "XGROUP" "CREATE" stream group "0" MKSTREAM
OK
127.0.0.1:6379> XINFO GROUPS stream
1)  1) "name"
    2) "group"
    3) "consumers"
    4) (integer) 0
    5) "pending"
    6) (integer) 0
    7) "last-delivered-id"
    8) "0-0"
    9) "entries-read"
   10) (nil)
   11) "lag"
   12) (integer) 0

@@ -157,9 +157,9 @@ TEST_F(RdbTest, Stream) {
EXPECT_THAT(resp, ArrLen(2));

resp = Run({"xinfo", "groups", "key:1"}); // test dereferences array of size 1
EXPECT_THAT(resp, ArrLen(8));
EXPECT_THAT(resp.GetVec(), ElementsAre("name", "g2", "consumers", IntArg(0), "pending", IntArg(0),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While here, you could use the newer syntax:
EXPECT_THAT(resp, RespArray(ElementsAre(...)));

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice, thanks!

Comment on lines 81 to 82
long long entries_read;
long long lag;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In our (as opposed to Redis') code, we prefer strict types such as int64_t over unspecified long long

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

@@ -884,6 +888,7 @@ OpStatus OpCreate(const OpArgs& op_args, string_view key, const CreateOpts& opts
auto* shard = op_args.shard;
auto& db_slice = shard->db_slice();
OpResult<PrimeIterator> res_it = db_slice.Find(op_args.db_cntx, key, OBJ_STREAM);
long entries_read = SCG_INVALID_ENTRIES_READ;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed.

TEST_F(StreamFamilyTest, XInfo) {
Run({"xgroup", "create", "foo", "cgroup", "0", "mkstream"});
auto resp = Run({"xinfo", "groups", "foo"});
EXPECT_THAT(resp.GetVec(), ElementsAre("name", "cgroup", "consumers", IntArg(0), "pending",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, please use EXPECT_THAT(resp, RespArray(ElementsAre(...)))
It has the advantage of not crashing if the result is not an array (that's why in many cases we used to add a check that the result is an array)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

@theyueli theyueli merged commit a2457e3 into dragonflydb:main Sep 28, 2023
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

feat (Streams): Support entries-read and lag fields in XINFO GROUPS command output
2 participants