The problem/use-case that the feature addresses
Today if I MSET some keys which are subject to client tracking the client will receive a separate invalidate message for each of those keys. An atomic operation has occurred in the Redis server, but the client just sees a stream of updates that it cannot (safely / reasonably) consider a batch.
Description of the feature
Atomic operations for keys being tracked should result in one invalidate message per client. There is already an array inside of an invalidate message that today happens to be always of size 1, so this can be done without a protocol change.
I would love to get feedback on this as an idea of something that Redis should probably do. I don't have a timeline for implementing it but am thinking about it. If anyone else wants to implement I am also not offended in the least.
Additional information
Need to take MULTI into account here.
Comment From: madolson
This was something I brought up to salvatore at some point. I think we could consider it a bug, since it allows you to end up with inconsistent reads. Would probably need some time to investigate the design though.
Comment From: oranagra
Question: for the purpose of client side caching, does it matter if the client sees these as a batch or individual messages?
@madolson can you locate your chat with Salvatore and post the discussion here? so we can see what was his opinion on that.
p.s. although the protocol supports it, changing it to return more than one element might break some client (or cause it to miss invalidations and induce an application bug). maybe we should try to look for evidence in a few client libraries and see if that's safe or not.
Comment From: lukepalmer
@oranagra good thought about returning more than one element. I've observed that when using BCAST the client will sometimes receive invalidation arrays that are not of size 1. AFAICT this isn't documented in the protocol.
So: I think that particular concern should be a non-issue here: if clients are expecting size 1 then they are already broken :(
Comment From: oranagra
That's nice to know, but i'm not sure that argument is enough. Since the response size is currently controlled by the client's input (using BCAST or not), a client / application can rely on it (and have no bugs). I.E. An application that's not using BCAST may be relying on getting an array with just one.
Not sure that's a justification not to do that change. however maybe it should be shipped in a major version together (which people test before rolling to production) with a clear note about the change
Comment From: madolson
@oranagra Salvatore apparently just ignored it. It was in a block of other suggestions and he addressed some of them, but not this one.
Comment From: madolson
I was reading through the lettuce implementation, and they seem to only handle it for respv3 version, but they do so correctly. You can build an extension for respv2 (Although not sure why you would). They also don't support the Null flush semantic.
https://github.com/lettuce-io/lettuce-core/releases#:~:text=Lettuce%20provides%20a%20CacheFrontend%20that,is%20exposed%20through%20a%20CacheFrontend%20.