When client tracking is on, invalidation message of flushdb in a (#11038)

When FLUSHDB / FLUSHALL / SWAPDB is inside MULTI / EXEC, the
client side tracking invalidation message was interleaved with transaction response.
This commit is contained in:
Huang Zhw 2022-07-26 18:28:37 +08:00 committed by GitHub
parent 020e046b42
commit 6f0a27e38e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 20 additions and 1 deletions

View File

@ -454,7 +454,12 @@ void trackingInvalidateKeysOnFlush(int async) {
while ((ln = listNext(&li)) != NULL) {
client *c = listNodeValue(ln);
if (c->flags & CLIENT_TRACKING) {
sendTrackingMessage(c,shared.null[c->resp]->ptr,sdslen(shared.null[c->resp]->ptr),1);
if (c == server.current_client) {
incrRefCount(shared.null[c->resp]);
listAddNodeTail(server.tracking_pending_keys,shared.null[c->resp]);
} else {
sendTrackingMessage(c,shared.null[c->resp]->ptr,sdslen(shared.null[c->resp]->ptr),1);
}
}
}
}

View File

@ -548,6 +548,20 @@ start_server {tags {"tracking network"}} {
assert_equal [lindex [$rd_redirection read] 2] {}
}
test {flushdb tracking invalidation message is not interleaved with transaction response} {
clean_all
r HELLO 3
r CLIENT TRACKING on
r SET a{t} 1
r GET a{t}
r MULTI
r FLUSHDB
set res [r EXEC]
assert_equal $res {OK}
# Consume the invalidate message which is after command response
r read
} {invalidate *_*}
# Keys are defined to be evicted 100 at a time by default.
# If after eviction the number of keys still surpasses the limit
# defined in tracking-table-max-keys, we increases eviction