Describe the bug
Changing a key in some db will produce invalidation messages for all clients who have a key with the same name in SOME database. e.g., if client 1 is in db 1, client 2 is in db 2, client 3 is in db 3, and all three dbs contain a key named "key" which is tracked by the clients, then changing key in db 1 will produce invalidation messages for all three of the clients.
To reproduce
For example:
client 1 is used as a redirection client for client 2. client 3 is used as a redirection client for client 4.
client 5:
set a 1
client 2: select 1
get a
client 4: select 2
get a
client 5:
set a 2
at this point, invalidation messages are produced in the redirection clients.
Expected behavior
For the above example, I would expect no invalidation messages to be produced, since client 5 was in db 0, and the other clients were not. In the case where one of the other clients were on db 0, I would expect an invalidation message to be produced only there.
Additional Info
I think this happens because the tracking table maps key->id, without anything to do with db num. We can change this to be (map, key)->id, or to have one tracking table per db, instead of just one global tracking table.
Comment From: nitaicaro
Found in the docs:
There is a single keys namespace, not divided by database numbers. So if a client is caching the key foo in database 2, and some other client changes the value of the key foo in database 3, an invalidation message will still be sent. This way we can ignore database numbers reducing both the memory usage and the implementation complexity.
Seems like this is intended.