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

Python: add XINFO STREAM command #1816

Merged

Conversation

aaron-congo
Copy link
Collaborator

@aaron-congo aaron-congo commented Jul 4, 2024

Issue #, if available:
N/A

Description of changes:
https://redis.io/docs/latest/commands/xinfo-stream/

  • Note 1: The value conversion is a work-in-progress, so please do not focus reviews on that section. You can however review the value conversion tests. The Python integration tests are passing for RESP3 but failing on RESP2 because the value conversion still needs some work.
  • Note 2: I will need to rebase onto main, however I will hold off on doing this because we have two people working on this branch.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@aaron-congo aaron-congo force-pushed the python/integ_acongo_xinfo_stream branch from 37542ef to 3b70d43 Compare July 4, 2024 23:11
@aaron-congo aaron-congo marked this pull request as ready for review July 4, 2024 23:11
@aaron-congo aaron-congo requested a review from a team as a code owner July 4, 2024 23:11
return Err((ErrorKind::TypeError, "Groups key not found").into());
};

if array.get(groups_index + 1).is_none() {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Not sure if we need it here, but you might want to add an overflow check here, in case groups_index is usize::MAX

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Definitely a good callout, but I don't think it is needed. usize::MAX is 18_446_744_073_709_551_615, but groups_index + 1 is always 18 with the current version of redis. For this to overflow, valkey would have to add enough fields in this array to boost that number over usize::MAX, which seems very unlikely.

glide-core/src/client/value_conversion.rs Outdated Show resolved Hide resolved
*/
ExpectedReturnType::XInfoStreamFullReturnType => match value {
Value::Map(_) => Ok(value), // Response is already in RESP3 format - no conversion needed
Value::Array(mut array) => {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Could probably refactor some of this code, since it's repetitive in some areas. We're essentially using the array like an association list, so we probably could write a (zero-cost) abstraction around this behaviour to make things a bit easier to reason about. Not a blocker, but something to think about.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, not sure if we will get around to it in this PR but we'll see. I agree that we can probably do some refactoring here to improve things

glide-core/src/client/value_conversion.rs Outdated Show resolved Hide resolved
glide-core/src/client/value_conversion.rs Show resolved Hide resolved

if groups.is_empty() {
let converted_response = convert_to_expected_type(Value::Array(array), Some(ExpectedReturnType::Map {
key_type: &Some(ExpectedReturnType::BulkString),
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
key_type: &Some(ExpectedReturnType::BulkString),
key_type: &Some(ExpectedReturnType::SimpleString),

Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't understand how it causes nested map[] to convert

Copy link
Collaborator Author

@aaron-congo aaron-congo Jul 5, 2024

Choose a reason for hiding this comment

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

This line is covering the scenario where "groups" is empty, i.e. there are no groups for the stream. Usually the nested maps are inside of groups (each group needs to be converted to a map, and each consumer inside that group map needs to be converted to a map). But since groups is empty in this block there are no nested maps that we need to convert

Copy link
Collaborator

Choose a reason for hiding this comment

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

Oh I see
So you just flat the recursion into a nested loops.
Maybe we need to rework it in the CompletableFuture

python/python/glide/async_commands/core.py Show resolved Hide resolved
python/python/glide/async_commands/core.py Show resolved Hide resolved
python/python/glide/async_commands/core.py Show resolved Hide resolved
python/python/tests/test_async_client.py Show resolved Hide resolved
python/python/tests/test_transaction.py Show resolved Hide resolved
glide-core/src/client/value_conversion.rs Show resolved Hide resolved
glide-core/src/client/value_conversion.rs Show resolved Hide resolved
@@ -214,6 +214,7 @@ pub enum RequestType {
XAutoClaim = 203,
XInfoGroups = 204,
XInfoConsumers = 205,
XInfoStream = 207,
Scan = 206,
Copy link
Collaborator

Choose a reason for hiding this comment

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

this ordering is unacceptable!

Copy link
Collaborator Author

@aaron-congo aaron-congo Jul 5, 2024

Choose a reason for hiding this comment

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

Lol 206 was stolen from me, it was either group the XInfo commands together but have weird numerical ordering or group them apart but have consistently increasing number values. I didn't want to change the scan numerical value to 207 because that could mess with other people's local code if they forget to rebuild after pulling this change

Copy link
Collaborator

Choose a reason for hiding this comment

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

you could've kept the numbers while swapping the ordering 😆 - welp, too late.

Copy link
Collaborator

@Yury-Fridlyand Yury-Fridlyand left a comment

Choose a reason for hiding this comment

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

I disagree with having bulk strings as map keys in the response, but this probably should be updated for all related commands together.
LGTM

@acarbonetto
Copy link
Collaborator

I disagree with having bulk strings as map keys in the response, but this probably should be updated for all related commands together.

Yes. A cleanup task for both teams to make a conscious effort to refactor and cleanup typing. We have way too much code and quite a bit of hand-waving going on in this file. Something to address in the coming month(s).

@acarbonetto acarbonetto merged commit a939df4 into valkey-io:main Jul 5, 2024
79 checks passed
@acarbonetto acarbonetto deleted the python/integ_acongo_xinfo_stream branch July 5, 2024 00:56
@Yury-Fridlyand Yury-Fridlyand mentioned this pull request Jul 5, 2024
cyip10 pushed a commit to Bit-Quill/valkey-glide that referenced this pull request Jul 16, 2024
* Grab value conversion from Java draft PR

* wip

* wip

* refactor value conversion wip

* Make value_conversion build

* Add value conversion test

* Verified test values

* Fix errors in test

* RESP3 tests passing

* Tests passing for RESP3, mypy passing

* Update CHANGELOG, minor doc fix

* Fix failing value conversion test

* Clean up value_conversion.rs a bit

* minor cleanup

* Modify test to cover failing scenario

* Python tests passing

* Fix test function signatures

* Fix failing pytest, cleanup value conversion comments

* PR suggestions

---------

Co-authored-by: Jonathan Louie <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: No status
Development

Successfully merging this pull request may close these issues.

5 participants