Expiration based invalidation PUSH messages sometimes embedded within other replies. #8935
Description
I sometimes see CLIENT TRACKING key invalidation messages embedded within an outer multi-bulk reply, which I believe is not supposed to happen.
Push data may be interleaved with any protocol data, but always at the top level, so the client will never find push data in the middle of a Map reply for instance.
To reproduce
Compile and run this code locally. The problem doesn't occur every run but it does more often than not so it shouldn't take any time to reproduce.
The heart of the logic that triggers the problem is as follows:
/* Set some fast expiring keys and immetiately request them back */
execAndDumpCommand(c, r, 0, "PSETEX %s %d %s", "key:0", 10, "A");
execAndDumpCommand(c, r, 0, "GETBIT %s %d", "key:0", 1);
execAndDumpCommand(c, r, 0, "PSETEX %s %d %s", "key:1", 10, "A");
execAndDumpCommand(c, r, 0, "GETBIT %s %d", "key:1", 1);
execAndDumpCommand(c, r, 0, "PSETEX %s %d %s", "key:2", 10, "A");
execAndDumpCommand(c, r, 0, "GETBIT %s %d", "key:2", 1);
/* Invoke MGET against the keys with a short delay between calls.
* At some point Redis will fire the expiration invalidation which
* sometimes is embedded inside the MGET multi-bulk reply. */
execAndDumpCommand(c, r, 1, "MGET %s", "key:0");
usleep(10000);
execAndDumpCommand(c, r, 1, "MGET %s", "key:1");
usleep(10000);
execAndDumpCommand(c, r, 1, "MGET %s", "key:2");
usleep(10000);Just to make sure I wasn't going crazy I also reproduced the behavior in a docker container.
Expected behavior
Push messages should always exist as top-level replies.
Additional information
redis-cli info
tcpflow data showing the raw replies
As always I'm happy to help test any fixes, etc
Cheers!