Fail XREAD[GROUP] if duplicate keys were given #11705
Conversation
Fix redis#11488 (see discussion there for more deatails) When using RESP3, XREAD[GROUP] returns a map, so it can't have duplicate keys. Instead of breaking the protocol (among other suggestions) we decided to ban using duplicate keys for these commands.
| @@ -2247,6 +2247,17 @@ void xreadCommand(client *c) { | |||
| return; | |||
| } | |||
|
|
|||
| for (int i = streams_arg + streams_count; i < c->argc; i++) { | |||
| for (int j = i + 1; j < c->argc; j++) { | |||
There was a problem hiding this comment.
Small question which might not be super important- does that implies that the command is no longer O(NM) where N=number of keys and M is the number of msgs returned by each key, but rather O(N^2+NM)?
There was a problem hiding this comment.
good point, i'll update the json files
There was a problem hiding this comment.
considering N is expected to be rather low, maybe it shouldn't be there?
@itamarhaber?
There was a problem hiding this comment.
or if it isn't expected to be always rather low, maybe this change is wrong..
There was a problem hiding this comment.
also with the new blocking mechanism we will repeat this when reprocessing... might be able to optimize in case this is run during unblock?
Alternative might also be to keep some bit filter on the keys (like simple bloom filter), but again in the worse case it will still be (N^2)
There was a problem hiding this comment.
yes, we can skip that validation in that case, but in order to do that we'll probably need to add a new flag to the client struct, saying we are reprocessing after unblocking... sounds good?
i'm wondering if there are any other expensive validations/calculations we can skip in other commands... can you please have a quick look?
There was a problem hiding this comment.
I am sure we could spare some checks, but I will argue that every command should have arity check function (could even be generated automatically from json), so we could better way to separate the 2 calls and fail the command on invalid arguments at much earlier stage. However that is a big change, and I guess making this case O(2(N^2)+NM) is not the critical thing.
To you question - the only flag that can currently be used is the CLIENT_UNBLOCKED flag... but that might change in the future
There was a problem hiding this comment.
Shall we restrict this PR to just adding validation for duplicate key access in XREAD[GROUP] and probably file a separate issue/PR for avoiding revalidation during reprocessing ?
There was a problem hiding this comment.
yeah, we can.. that way we can maybe handle the re-validation optimization earlier.
|
let's re-consider this, see #11488 (comment) |
|
|
Fix #11488 (see discussion there for more details)
When using RESP3, XREAD[GROUP] returns a map, so it can't have duplicate keys.
Instead of breaking the protocol (among other suggestions) we decided to ban using duplicate keys for these commands.