redict/tests/unit/multi.tcl

608 lines
16 KiB
Tcl
Raw Normal View History

start_server {tags {"multi"}} {
test {MUTLI / EXEC basics} {
r del mylist
r rpush mylist a
r rpush mylist b
r rpush mylist c
r multi
set v1 [r lrange mylist 0 -1]
set v2 [r ping]
set v3 [r exec]
list $v1 $v2 $v3
} {QUEUED QUEUED {{a b c} PONG}}
test {DISCARD} {
r del mylist
r rpush mylist a
r rpush mylist b
r rpush mylist c
r multi
set v1 [r del mylist]
set v2 [r discard]
set v3 [r lrange mylist 0 -1]
list $v1 $v2 $v3
} {QUEUED OK {a b c}}
test {Nested MULTI are not allowed} {
set err {}
r multi
catch {[r multi]} err
r exec
set _ $err
} {*ERR MULTI*}
test {MULTI where commands alter argc/argv} {
r sadd myset a
r multi
r spop myset
list [r exec] [r exists myset]
} {a 0}
test {WATCH inside MULTI is not allowed} {
set err {}
r multi
catch {[r watch x]} err
r exec
set _ $err
} {*ERR WATCH*}
test {EXEC fails if there are errors while queueing commands #1} {
r del foo1 foo2
r multi
r set foo1 bar1
catch {r non-existing-command}
r set foo2 bar2
catch {r exec} e
assert_match {EXECABORT*} $e
list [r exists foo1] [r exists foo2]
} {0 0}
test {EXEC fails if there are errors while queueing commands #2} {
set rd [redis_deferring_client]
r del foo1 foo2
r multi
r set foo1 bar1
$rd config set maxmemory 1
2012-11-29 10:12:14 -05:00
assert {[$rd read] eq {OK}}
catch {r lpush mylist myvalue}
$rd config set maxmemory 0
2012-11-29 10:12:14 -05:00
assert {[$rd read] eq {OK}}
r set foo2 bar2
catch {r exec} e
assert_match {EXECABORT*} $e
$rd close
list [r exists foo1] [r exists foo2]
} {0 0}
test {If EXEC aborts, the client MULTI state is cleared} {
r del foo1 foo2
r multi
r set foo1 bar1
catch {r non-existing-command}
r set foo2 bar2
catch {r exec} e
assert_match {EXECABORT*} $e
r ping
} {PONG}
2010-05-25 08:04:46 -04:00
test {EXEC works on WATCHed key not modified} {
r watch x y z
r watch k
r multi
r ping
r exec
} {PONG}
test {EXEC fail on WATCHed key modified (1 key of 1 watched)} {
r set x 30
r watch x
r set x 40
r multi
r ping
r exec
} {}
test {EXEC fail on WATCHed key modified (1 key of 5 watched)} {
r set x 30
r watch a b x k z
r set x 40
r multi
r ping
r exec
} {}
test {EXEC fail on WATCHed key modified by SORT with STORE even if the result is empty} {
r flushdb
r lpush foo bar
r watch foo
r sort emptylist store foo
r multi
r ping
r exec
} {}
2010-05-25 08:04:46 -04:00
test {After successful EXEC key is no longer watched} {
r set x 30
r watch x
r multi
r ping
r exec
r set x 40
r multi
r ping
r exec
} {PONG}
test {After failed EXEC key is no longer watched} {
r set x 30
r watch x
r set x 40
r multi
r ping
r exec
r set x 40
r multi
r ping
r exec
} {PONG}
test {It is possible to UNWATCH} {
r set x 30
r watch x
r set x 40
r unwatch
r multi
r ping
r exec
} {PONG}
test {UNWATCH when there is nothing watched works as expected} {
r unwatch
} {OK}
test {FLUSHALL is able to touch the watched keys} {
r set x 30
r watch x
r flushall
r multi
r ping
r exec
} {}
test {FLUSHALL does not touch non affected keys} {
r del x
r watch x
r flushall
r multi
r ping
r exec
} {PONG}
test {FLUSHDB is able to touch the watched keys} {
r set x 30
r watch x
r flushdb
r multi
r ping
r exec
} {}
test {FLUSHDB does not touch non affected keys} {
r del x
r watch x
r flushdb
r multi
r ping
r exec
} {PONG}
test {WATCH is able to remember the DB a key belongs to} {
r select 5
r set x 30
r watch x
r select 1
r set x 10
r select 5
r multi
r ping
set res [r exec]
# Restore original DB
r select 9
set res
} {PONG}
test {WATCH will consider touched keys target of EXPIRE} {
r del x
r set x foo
r watch x
r expire x 10
r multi
r ping
r exec
} {}
test {WATCH will consider touched expired keys} {
r del x
r set x foo
2011-11-25 06:27:00 -05:00
r expire x 1
r watch x
2011-11-25 06:27:00 -05:00
after 1100
r multi
r ping
r exec
} {}
2011-11-25 06:27:00 -05:00
test {DISCARD should clear the WATCH dirty flag on the client} {
r watch x
r set x 10
r multi
r discard
r multi
r incr x
r exec
} {11}
test {DISCARD should UNWATCH all the keys} {
r watch x
r set x 10
r multi
r discard
r set x 10
r multi
r incr x
r exec
} {11}
2013-03-27 06:31:27 -04:00
test {MULTI / EXEC is propagated correctly (single write command)} {
set repl [attach_to_replication_stream]
r multi
r set foo bar
r exec
assert_replication_stream $repl {
{select *}
{multi}
{set foo bar}
{exec}
}
close_replication_stream $repl
}
test {MULTI / EXEC is propagated correctly (empty transaction)} {
set repl [attach_to_replication_stream]
r multi
r exec
r set foo bar
assert_replication_stream $repl {
{select *}
{set foo bar}
}
close_replication_stream $repl
}
test {MULTI / EXEC is propagated correctly (read-only commands)} {
r set foo value1
set repl [attach_to_replication_stream]
r multi
r get foo
r exec
r set foo value2
assert_replication_stream $repl {
{select *}
{set foo value2}
}
close_replication_stream $repl
}
test {MULTI / EXEC is propagated correctly (write command, no effect)} {
r del bar foo bar
set repl [attach_to_replication_stream]
r multi
r del foo
r exec
Remove read-only flag from non-keyspace cmds, different approach for EXEC to propagate MULTI (#8216) In the distant history there was only the read flag for commands, and whatever command that didn't have the read flag was a write one. Then we added the write flag, but some portions of the code still used !read Also some commands that don't work on the keyspace at all, still have the read flag. Changes in this commit: 1. remove the read-only flag from TIME, ECHO, ROLE and LASTSAVE 2. EXEC command used to decides if it should propagate a MULTI by looking at the command flags (!read & !admin). When i was about to change it to look at the write flag instead, i realized that this would cause it not to propagate a MULTI for PUBLISH, EVAL, and SCRIPT, all 3 are not marked as either a read command or a write one (as they should), but all 3 are calling forceCommandPropagation. So instead of introducing a new flag to denote a command that "writes" but not into the keyspace, and still needs propagation, i decided to rely on the forceCommandPropagation, and just fix the code to propagate MULTI when needed rather than depending on the command flags at all. The implication of my change then is that now it won't decide to propagate MULTI when it sees one of these: SELECT, PING, INFO, COMMAND, TIME and other commands which are neither read nor write. 3. Changing getNodeByQuery and clusterRedirectBlockedClientIfNeeded in cluster.c to look at !write rather than read flag. This should have no implications, since these code paths are only reachable for commands which access keys, and these are always marked as either read or write. This commit improve MULTI propagation tests, for modules and a bunch of other special cases, all of which used to pass already before that commit. the only one that test change that uncovered a change of behavior is the one that DELs a non-existing key, it used to propagate an empty multi-exec block, and no longer does.
2020-12-22 05:03:49 -05:00
# add another command so that when we see it we know multi-exec wasn't
# propagated
r incr foo
2013-03-27 06:31:27 -04:00
assert_replication_stream $repl {
{select *}
Remove read-only flag from non-keyspace cmds, different approach for EXEC to propagate MULTI (#8216) In the distant history there was only the read flag for commands, and whatever command that didn't have the read flag was a write one. Then we added the write flag, but some portions of the code still used !read Also some commands that don't work on the keyspace at all, still have the read flag. Changes in this commit: 1. remove the read-only flag from TIME, ECHO, ROLE and LASTSAVE 2. EXEC command used to decides if it should propagate a MULTI by looking at the command flags (!read & !admin). When i was about to change it to look at the write flag instead, i realized that this would cause it not to propagate a MULTI for PUBLISH, EVAL, and SCRIPT, all 3 are not marked as either a read command or a write one (as they should), but all 3 are calling forceCommandPropagation. So instead of introducing a new flag to denote a command that "writes" but not into the keyspace, and still needs propagation, i decided to rely on the forceCommandPropagation, and just fix the code to propagate MULTI when needed rather than depending on the command flags at all. The implication of my change then is that now it won't decide to propagate MULTI when it sees one of these: SELECT, PING, INFO, COMMAND, TIME and other commands which are neither read nor write. 3. Changing getNodeByQuery and clusterRedirectBlockedClientIfNeeded in cluster.c to look at !write rather than read flag. This should have no implications, since these code paths are only reachable for commands which access keys, and these are always marked as either read or write. This commit improve MULTI propagation tests, for modules and a bunch of other special cases, all of which used to pass already before that commit. the only one that test change that uncovered a change of behavior is the one that DELs a non-existing key, it used to propagate an empty multi-exec block, and no longer does.
2020-12-22 05:03:49 -05:00
{incr foo}
2013-03-27 06:31:27 -04:00
}
close_replication_stream $repl
}
test {DISCARD should not fail during OOM} {
set rd [redis_deferring_client]
$rd config set maxmemory 1
assert {[$rd read] eq {OK}}
r multi
catch {r set x 1} e
assert_match {OOM*} $e
r discard
$rd config set maxmemory 0
assert {[$rd read] eq {OK}}
$rd close
r ping
} {PONG}
test {MULTI and script timeout} {
# check that if MULTI arrives during timeout, it is either refused, or
# allowed to pass, and we don't end up executing half of the transaction
set rd1 [redis_deferring_client]
set r2 [redis_client]
r config set lua-time-limit 10
r set xx 1
$rd1 eval {while true do end} 0
after 200
catch { $r2 multi; } e
catch { $r2 incr xx; } e
r script kill
after 200 ; # Give some time to Lua to call the hook again...
catch { $r2 incr xx; } e
catch { $r2 exec; } e
assert_match {EXECABORT*previous errors*} $e
set xx [r get xx]
# make sure that either the whole transcation passed or none of it (we actually expect none)
assert { $xx == 1 || $xx == 3}
# check that the connection is no longer in multi state
set pong [$r2 ping asdf]
assert_equal $pong "asdf"
$rd1 close; $r2 close
}
test {EXEC and script timeout} {
# check that if EXEC arrives during timeout, we don't end up executing
# half of the transaction, and also that we exit the multi state
set rd1 [redis_deferring_client]
set r2 [redis_client]
r config set lua-time-limit 10
r set xx 1
catch { $r2 multi; } e
catch { $r2 incr xx; } e
$rd1 eval {while true do end} 0
after 200
catch { $r2 incr xx; } e
catch { $r2 exec; } e
assert_match {EXECABORT*BUSY*} $e
r script kill
after 200 ; # Give some time to Lua to call the hook again...
set xx [r get xx]
# make sure that either the whole transcation passed or none of it (we actually expect none)
assert { $xx == 1 || $xx == 3}
# check that the connection is no longer in multi state
set pong [$r2 ping asdf]
assert_equal $pong "asdf"
$rd1 close; $r2 close
}
test {MULTI-EXEC body and script timeout} {
# check that we don't run an imcomplete transaction due to some commands
# arriving during busy script
set rd1 [redis_deferring_client]
set r2 [redis_client]
r config set lua-time-limit 10
r set xx 1
catch { $r2 multi; } e
catch { $r2 incr xx; } e
$rd1 eval {while true do end} 0
after 200
catch { $r2 incr xx; } e
r script kill
after 200 ; # Give some time to Lua to call the hook again...
catch { $r2 exec; } e
assert_match {EXECABORT*previous errors*} $e
set xx [r get xx]
# make sure that either the whole transcation passed or none of it (we actually expect none)
assert { $xx == 1 || $xx == 3}
# check that the connection is no longer in multi state
set pong [$r2 ping asdf]
assert_equal $pong "asdf"
$rd1 close; $r2 close
}
test {just EXEC and script timeout} {
# check that if EXEC arrives during timeout, we don't end up executing
# actual commands during busy script, and also that we exit the multi state
set rd1 [redis_deferring_client]
set r2 [redis_client]
r config set lua-time-limit 10
r set xx 1
catch { $r2 multi; } e
catch { $r2 incr xx; } e
$rd1 eval {while true do end} 0
after 200
catch { $r2 exec; } e
assert_match {EXECABORT*BUSY*} $e
r script kill
after 200 ; # Give some time to Lua to call the hook again...
set xx [r get xx]
# make we didn't execute the transaction
assert { $xx == 1}
# check that the connection is no longer in multi state
set pong [$r2 ping asdf]
assert_equal $pong "asdf"
$rd1 close; $r2 close
}
test {exec with write commands and state change} {
# check that exec that contains write commands fails if server state changed since they were queued
set r1 [redis_client]
r set xx 1
r multi
r incr xx
$r1 config set min-replicas-to-write 2
catch {r exec} e
assert_match {*EXECABORT*NOREPLICAS*} $e
set xx [r get xx]
# make sure that the INCR wasn't executed
assert { $xx == 1}
$r1 config set min-replicas-to-write 0
$r1 close;
}
test {exec with read commands and stale replica state change} {
# check that exec that contains read commands fails if server state changed since they were queued
r config set replica-serve-stale-data no
set r1 [redis_client]
r set xx 1
# check that GET is disallowed on stale replica, even if the replica becomes stale only after queuing.
r multi
r get xx
$r1 replicaof localhsot 0
catch {r exec} e
assert_match {*EXECABORT*MASTERDOWN*} $e
# check that PING is allowed
r multi
r ping
$r1 replicaof localhsot 0
set pong [r exec]
assert {$pong == "PONG"}
# check that when replica is not stale, GET is allowed
# while we're at it, let's check that multi is allowed on stale replica too
r multi
$r1 replicaof no one
r get xx
set xx [r exec]
# make sure that the INCR was executed
assert { $xx == 1 }
$r1 close;
}
test {EXEC with only read commands should not be rejected when OOM} {
set r2 [redis_client]
r set x value
r multi
r get x
r ping
# enforcing OOM
$r2 config set maxmemory 1
# finish the multi transaction with exec
assert { [r exec] == {value PONG} }
# releasing OOM
$r2 config set maxmemory 0
$r2 close
}
test {EXEC with at least one use-memory command should fail} {
set r2 [redis_client]
r multi
r set x 1
r get x
# enforcing OOM
$r2 config set maxmemory 1
# finish the multi transaction with exec
catch {r exec} e
assert_match {EXECABORT*OOM*} $e
# releasing OOM
$r2 config set maxmemory 0
$r2 close
}
Unified MULTI, LUA, and RM_Call with respect to blocking commands (#8025) Blocking command should not be used with MULTI, LUA, and RM_Call. This is because, the caller, who executes the command in this context, expects a reply. Today, LUA and MULTI have a special (and different) treatment to blocking commands: LUA - Most commands are marked with no-script flag which are checked when executing and command from LUA, commands that are not marked (like XREAD) verify that their blocking mode is not used inside LUA (by checking the CLIENT_LUA client flag). MULTI - Command that is going to block, first verify that the client is not inside multi (by checking the CLIENT_MULTI client flag). If the client is inside multi, they return a result which is a match to the empty key with no timeout (for example blpop inside MULTI will act as lpop) For modules that perform RM_Call with blocking command, the returned results type is REDISMODULE_REPLY_UNKNOWN and the caller can not really know what happened. Disadvantages of the current state are: No unified approach, LUA, MULTI, and RM_Call, each has a different treatment Module can not safely execute blocking command (and get reply or error). Though It is true that modules are not like LUA or MULTI and should be smarter not to execute blocking commands on RM_Call, sometimes you want to execute a command base on client input (for example if you create a module that provides a new scripting language like javascript or python). While modules (on modules command) can check for REDISMODULE_CTX_FLAGS_LUA or REDISMODULE_CTX_FLAGS_MULTI to know not to block the client, there is no way to check if the command came from another module using RM_Call. So there is no way for a module to know not to block another module RM_Call execution. This commit adds a way to unify the treatment for blocking clients by introducing a new CLIENT_DENY_BLOCKING client flag. On LUA, MULTI, and RM_Call the new flag turned on to signify that the client should not be blocked. A blocking command verifies that the flag is turned off before blocking. If a blocking command sees that the CLIENT_DENY_BLOCKING flag is on, it's not blocking and return results which are matches to empty key with no timeout (as MULTI does today). The new flag is checked on the following commands: List blocking commands: BLPOP, BRPOP, BRPOPLPUSH, BLMOVE, Zset blocking commands: BZPOPMIN, BZPOPMAX Stream blocking commands: XREAD, XREADGROUP SUBSCRIBE, PSUBSCRIBE, MONITOR In addition, the new flag is turned on inside the AOF client, we do not want to block the AOF client to prevent deadlocks and commands ordering issues (and there is also an existing assert in the code that verifies it). To keep backward compatibility on LUA, all the no-script flags on existing commands were kept untouched. In addition, a LUA special treatment on XREAD and XREADGROUP was kept. To keep backward compatibility on MULTI (which today allows SUBSCRIBE, and PSUBSCRIBE). We added a special treatment on those commands to allow executing them on MULTI. The only backward compatibility issue that this PR introduces is that now MONITOR is not allowed inside MULTI. Tests were added to verify blocking commands are not blocking the client on LUA, MULTI, or RM_Call. Tests were added to verify the module can check for CLIENT_DENY_BLOCKING flag. Co-authored-by: Oran Agra <oran@redislabs.com> Co-authored-by: Itamar Haber <itamar@redislabs.com>
2020-11-17 11:58:55 -05:00
test {Blocking commands ignores the timeout} {
r xgroup create s g $ MKSTREAM
set m [r multi]
r blpop empty_list 0
r brpop empty_list 0
r brpoplpush empty_list1 empty_list2 0
r blmove empty_list1 empty_list2 LEFT LEFT 0
r bzpopmin empty_zset 0
r bzpopmax empty_zset 0
r xread BLOCK 0 STREAMS s $
r xreadgroup group g c BLOCK 0 STREAMS s >
set res [r exec]
list $m $res
} {OK {{} {} {} {} {} {} {} {}}}
Remove read-only flag from non-keyspace cmds, different approach for EXEC to propagate MULTI (#8216) In the distant history there was only the read flag for commands, and whatever command that didn't have the read flag was a write one. Then we added the write flag, but some portions of the code still used !read Also some commands that don't work on the keyspace at all, still have the read flag. Changes in this commit: 1. remove the read-only flag from TIME, ECHO, ROLE and LASTSAVE 2. EXEC command used to decides if it should propagate a MULTI by looking at the command flags (!read & !admin). When i was about to change it to look at the write flag instead, i realized that this would cause it not to propagate a MULTI for PUBLISH, EVAL, and SCRIPT, all 3 are not marked as either a read command or a write one (as they should), but all 3 are calling forceCommandPropagation. So instead of introducing a new flag to denote a command that "writes" but not into the keyspace, and still needs propagation, i decided to rely on the forceCommandPropagation, and just fix the code to propagate MULTI when needed rather than depending on the command flags at all. The implication of my change then is that now it won't decide to propagate MULTI when it sees one of these: SELECT, PING, INFO, COMMAND, TIME and other commands which are neither read nor write. 3. Changing getNodeByQuery and clusterRedirectBlockedClientIfNeeded in cluster.c to look at !write rather than read flag. This should have no implications, since these code paths are only reachable for commands which access keys, and these are always marked as either read or write. This commit improve MULTI propagation tests, for modules and a bunch of other special cases, all of which used to pass already before that commit. the only one that test change that uncovered a change of behavior is the one that DELs a non-existing key, it used to propagate an empty multi-exec block, and no longer does.
2020-12-22 05:03:49 -05:00
test {MULTI propagation of PUBLISH} {
set repl [attach_to_replication_stream]
# make sure that PUBLISH inside MULTI is propagated in a transaction
r multi
r publish bla bla
r exec
assert_replication_stream $repl {
{select *}
{multi}
{publish bla bla}
{exec}
}
close_replication_stream $repl
}
test {MULTI propagation of SCRIPT LOAD} {
set repl [attach_to_replication_stream]
# make sure that SCRIPT LOAD inside MULTI is propagated in a transaction
r multi
r script load {redis.call('set', KEYS[1], 'foo')}
set res [r exec]
set sha [lindex $res 0]
assert_replication_stream $repl {
{select *}
{multi}
{script load *}
{exec}
}
close_replication_stream $repl
}
test {MULTI propagation of SCRIPT LOAD} {
set repl [attach_to_replication_stream]
# make sure that EVAL inside MULTI is propagated in a transaction
r config set lua-replicate-commands no
r multi
r eval {redis.call('set', KEYS[1], 'bar')} 1 bar
r exec
assert_replication_stream $repl {
{select *}
{multi}
{eval *}
{exec}
}
close_replication_stream $repl
}
tags {"stream"} {
test {MULTI propagation of XREADGROUP} {
# stream is a special case because it calls propagate() directly for XREADGROUP
set repl [attach_to_replication_stream]
r XADD mystream * foo bar
r XGROUP CREATE mystream mygroup 0
# make sure the XCALIM (propagated by XREADGROUP) is indeed inside MULTI/EXEC
r multi
r XREADGROUP GROUP mygroup consumer1 STREAMS mystream ">"
r exec
assert_replication_stream $repl {
{select *}
{xadd *}
{xgroup CREATE *}
{multi}
{xclaim *}
{exec}
}
close_replication_stream $repl
}
}
2010-05-25 08:04:46 -04:00
}