2020-09-09 09:01:16 -04:00
|
|
|
set testmodule [file normalize tests/modules/blockedclient.so]
|
|
|
|
|
|
|
|
start_server {tags {"modules"}} {
|
|
|
|
r module load $testmodule
|
|
|
|
|
|
|
|
test {Locked GIL acquisition} {
|
|
|
|
assert_match "OK" [r acquire_gil]
|
|
|
|
}
|
2020-10-11 10:21:58 -04:00
|
|
|
|
|
|
|
test {Locked GIL acquisition during multi} {
|
|
|
|
r multi
|
|
|
|
r acquire_gil
|
|
|
|
assert_equal {{Blocked client is not supported inside multi}} [r exec]
|
|
|
|
}
|
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 {Locked GIL acquisition from RM_Call} {
|
|
|
|
assert_equal {Blocked client is not allowed} [r do_rm_call acquire_gil]
|
|
|
|
}
|
|
|
|
|
|
|
|
test {Blocking command are not block the client on RM_Call} {
|
|
|
|
r lpush l test
|
|
|
|
assert_equal [r do_rm_call blpop l 0] {l test}
|
|
|
|
|
|
|
|
r lpush l test
|
|
|
|
assert_equal [r do_rm_call brpop l 0] {l test}
|
|
|
|
|
|
|
|
r lpush l1 test
|
|
|
|
assert_equal [r do_rm_call brpoplpush l1 l2 0] {test}
|
|
|
|
assert_equal [r do_rm_call brpop l2 0] {l2 test}
|
|
|
|
|
|
|
|
r lpush l1 test
|
|
|
|
assert_equal [r do_rm_call blmove l1 l2 LEFT LEFT 0] {test}
|
|
|
|
assert_equal [r do_rm_call brpop l2 0] {l2 test}
|
|
|
|
|
|
|
|
r ZADD zset1 0 a 1 b 2 c
|
|
|
|
assert_equal [r do_rm_call bzpopmin zset1 0] {zset1 a 0}
|
|
|
|
assert_equal [r do_rm_call bzpopmax zset1 0] {zset1 c 2}
|
|
|
|
|
|
|
|
r xgroup create s g $ MKSTREAM
|
|
|
|
r xadd s * foo bar
|
|
|
|
assert {[r do_rm_call xread BLOCK 0 STREAMS s 0-0] ne {}}
|
|
|
|
assert {[r do_rm_call xreadgroup group g c BLOCK 0 STREAMS s >] ne {}}
|
|
|
|
|
|
|
|
assert {[r do_rm_call blpop empty_list 0] eq {}}
|
|
|
|
assert {[r do_rm_call brpop empty_list 0] eq {}}
|
|
|
|
assert {[r do_rm_call brpoplpush empty_list1 empty_list2 0] eq {}}
|
|
|
|
assert {[r do_rm_call blmove empty_list1 empty_list2 LEFT LEFT 0] eq {}}
|
|
|
|
|
|
|
|
assert {[r do_rm_call bzpopmin empty_zset 0] eq {}}
|
|
|
|
assert {[r do_rm_call bzpopmax empty_zset 0] eq {}}
|
|
|
|
|
|
|
|
r xgroup create empty_stream g $ MKSTREAM
|
|
|
|
assert {[r do_rm_call xread BLOCK 0 STREAMS empty_stream $] eq {}}
|
|
|
|
assert {[r do_rm_call xreadgroup group g c BLOCK 0 STREAMS empty_stream >] eq {}}
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
test {Monitor disallow inside RM_Call} {
|
|
|
|
set e {}
|
|
|
|
catch {
|
|
|
|
r do_rm_call monitor
|
|
|
|
} e
|
|
|
|
set e
|
Adds pub/sub channel patterns to ACL (#7993)
Fixes #7923.
This PR appropriates the special `&` symbol (because `@` and `*` are taken),
followed by a literal value or pattern for describing the Pub/Sub patterns that
an ACL user can interact with. It is similar to the existing key patterns
mechanism in function (additive) and implementation (copy-pasta). It also adds
the allchannels and resetchannels ACL keywords, naturally.
The default user is given allchannels permissions, whereas new users get
whatever is defined by the acl-pubsub-default configuration directive. For
backward compatibility in 6.2, the default of this directive is allchannels but
this is likely to be changed to resetchannels in the next major version for
stronger default security settings.
Unless allchannels is set for the user, channel access permissions are checked
as follows :
* Calls to both PUBLISH and SUBSCRIBE will fail unless a pattern matching the
argumentative channel name(s) exists for the user.
* Calls to PSUBSCRIBE will fail unless the pattern(s) provided as an argument
literally exist(s) in the user's list.
Such failures are logged to the ACL log.
Runtime changes to channel permissions for a user with existing subscribing
clients cause said clients to disconnect unless the new permissions permit the
connections to continue. Note, however, that PSUBSCRIBErs' patterns are matched
literally, so given the change bar:* -> b*, pattern subscribers to bar:* will be
disconnected.
Notes/questions:
* UNSUBSCRIBE, PUNSUBSCRIBE and PUBSUB remain unprotected due to lack of reasons
for touching them.
2020-12-01 07:21:39 -05:00
|
|
|
} {*ERR*DENY BLOCKING*}
|
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 {subscribe disallow inside RM_Call} {
|
|
|
|
set e {}
|
|
|
|
catch {
|
|
|
|
r do_rm_call subscribe x
|
|
|
|
} e
|
|
|
|
set e
|
Adds pub/sub channel patterns to ACL (#7993)
Fixes #7923.
This PR appropriates the special `&` symbol (because `@` and `*` are taken),
followed by a literal value or pattern for describing the Pub/Sub patterns that
an ACL user can interact with. It is similar to the existing key patterns
mechanism in function (additive) and implementation (copy-pasta). It also adds
the allchannels and resetchannels ACL keywords, naturally.
The default user is given allchannels permissions, whereas new users get
whatever is defined by the acl-pubsub-default configuration directive. For
backward compatibility in 6.2, the default of this directive is allchannels but
this is likely to be changed to resetchannels in the next major version for
stronger default security settings.
Unless allchannels is set for the user, channel access permissions are checked
as follows :
* Calls to both PUBLISH and SUBSCRIBE will fail unless a pattern matching the
argumentative channel name(s) exists for the user.
* Calls to PSUBSCRIBE will fail unless the pattern(s) provided as an argument
literally exist(s) in the user's list.
Such failures are logged to the ACL log.
Runtime changes to channel permissions for a user with existing subscribing
clients cause said clients to disconnect unless the new permissions permit the
connections to continue. Note, however, that PSUBSCRIBErs' patterns are matched
literally, so given the change bar:* -> b*, pattern subscribers to bar:* will be
disconnected.
Notes/questions:
* UNSUBSCRIBE, PUNSUBSCRIBE and PUBSUB remain unprotected due to lack of reasons
for touching them.
2020-12-01 07:21:39 -05:00
|
|
|
} {*ERR*DENY BLOCKING*}
|
2020-12-08 09:41:20 -05:00
|
|
|
|
|
|
|
test {RM_Call from blocked client} {
|
|
|
|
r hset hash foo bar
|
|
|
|
r do_bg_rm_call hgetall hash
|
|
|
|
} {foo bar}
|
|
|
|
|
2021-10-21 07:01:10 -04:00
|
|
|
test {RESP version carries through to blocked client} {
|
|
|
|
for {set client_proto 2} {$client_proto <= 3} {incr client_proto} {
|
|
|
|
r hello $client_proto
|
|
|
|
r readraw 1
|
|
|
|
set ret [r do_fake_bg_true]
|
|
|
|
if {$client_proto == 2} {
|
|
|
|
assert_equal $ret {:1}
|
|
|
|
} else {
|
|
|
|
assert_equal $ret "#t"
|
|
|
|
}
|
|
|
|
r readraw 0
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-04-07 04:52:28 -04:00
|
|
|
foreach call_type {nested normal} {
|
|
|
|
test "Busy module command - $call_type" {
|
2022-01-20 02:05:53 -05:00
|
|
|
set busy_time_limit 50
|
|
|
|
set old_time_limit [lindex [r config get busy-reply-threshold] 1]
|
|
|
|
r config set busy-reply-threshold $busy_time_limit
|
|
|
|
set rd [redis_deferring_client]
|
|
|
|
|
|
|
|
# run command that blocks until released
|
|
|
|
set start [clock clicks -milliseconds]
|
2022-04-07 04:52:28 -04:00
|
|
|
if {$call_type == "nested"} {
|
|
|
|
$rd do_rm_call slow_fg_command 0
|
|
|
|
} else {
|
|
|
|
$rd slow_fg_command 0
|
|
|
|
}
|
2022-01-20 02:05:53 -05:00
|
|
|
$rd flush
|
|
|
|
|
|
|
|
# make sure we get BUSY error, and that we didn't get it too early
|
|
|
|
assert_error {*BUSY Slow module operation*} {r ping}
|
|
|
|
assert_morethan_equal [expr [clock clicks -milliseconds]-$start] $busy_time_limit
|
|
|
|
|
|
|
|
# abort the blocking operation
|
|
|
|
r stop_slow_fg_command
|
|
|
|
wait_for_condition 50 100 {
|
|
|
|
[catch {r ping} e] == 0
|
|
|
|
} else {
|
|
|
|
fail "Failed waiting for busy command to end"
|
|
|
|
}
|
|
|
|
$rd read
|
|
|
|
|
2022-04-07 04:52:28 -04:00
|
|
|
# run command that blocks for 200ms
|
2022-01-20 02:05:53 -05:00
|
|
|
set start [clock clicks -milliseconds]
|
2022-04-07 04:52:28 -04:00
|
|
|
if {$call_type == "nested"} {
|
|
|
|
$rd do_rm_call slow_fg_command 200000
|
|
|
|
} else {
|
|
|
|
$rd slow_fg_command 200000
|
|
|
|
}
|
2022-01-20 02:05:53 -05:00
|
|
|
$rd flush
|
|
|
|
after 10 ;# try to make sure redis started running the command before we proceed
|
|
|
|
|
|
|
|
# make sure we didn't get BUSY error, it simply blocked till the command was done
|
|
|
|
r ping
|
|
|
|
assert_morethan_equal [expr [clock clicks -milliseconds]-$start] 200
|
|
|
|
$rd read
|
|
|
|
|
|
|
|
$rd close
|
|
|
|
r config set busy-reply-threshold $old_time_limit
|
|
|
|
}
|
2022-04-07 04:52:28 -04:00
|
|
|
}
|
2022-01-20 02:05:53 -05:00
|
|
|
|
|
|
|
test {RM_Call from blocked client} {
|
|
|
|
set busy_time_limit 50
|
|
|
|
set old_time_limit [lindex [r config get busy-reply-threshold] 1]
|
|
|
|
r config set busy-reply-threshold $busy_time_limit
|
|
|
|
|
|
|
|
# trigger slow operation
|
|
|
|
r set_slow_bg_operation 1
|
|
|
|
r hset hash foo bar
|
|
|
|
set rd [redis_deferring_client]
|
|
|
|
set start [clock clicks -milliseconds]
|
|
|
|
$rd do_bg_rm_call hgetall hash
|
|
|
|
|
|
|
|
# wait till we know we're blocked inside the module
|
|
|
|
wait_for_condition 50 100 {
|
|
|
|
[r is_in_slow_bg_operation] eq 1
|
|
|
|
} else {
|
|
|
|
fail "Failed waiting for slow operation to start"
|
|
|
|
}
|
|
|
|
|
|
|
|
# make sure we get BUSY error, and that we didn't get here too early
|
|
|
|
assert_error {*BUSY Slow module operation*} {r ping}
|
|
|
|
assert_morethan [expr [clock clicks -milliseconds]-$start] $busy_time_limit
|
|
|
|
# abort the blocking operation
|
|
|
|
r set_slow_bg_operation 0
|
|
|
|
|
|
|
|
wait_for_condition 50 100 {
|
|
|
|
[r is_in_slow_bg_operation] eq 0
|
|
|
|
} else {
|
|
|
|
fail "Failed waiting for slow operation to stop"
|
|
|
|
}
|
|
|
|
assert_equal [r ping] {PONG}
|
|
|
|
|
|
|
|
r config set busy-reply-threshold $old_time_limit
|
|
|
|
set res [$rd read]
|
|
|
|
$rd close
|
|
|
|
set _ $res
|
|
|
|
} {foo bar}
|
|
|
|
|
2020-12-08 09:41:20 -05:00
|
|
|
test {blocked client reaches client output buffer limit} {
|
|
|
|
r hset hash big [string repeat x 50000]
|
|
|
|
r hset hash bada [string repeat x 50000]
|
|
|
|
r hset hash boom [string repeat x 50000]
|
|
|
|
r config set client-output-buffer-limit {normal 100000 0 0}
|
|
|
|
r client setname myclient
|
|
|
|
catch {r do_bg_rm_call hgetall hash} e
|
|
|
|
assert_match "*I/O error*" $e
|
|
|
|
reconnect
|
|
|
|
set clients [r client list]
|
|
|
|
assert_no_match "*name=myclient*" $clients
|
|
|
|
}
|
2022-01-23 03:05:06 -05:00
|
|
|
|
2022-02-13 11:37:32 -05:00
|
|
|
test {module client error stats} {
|
|
|
|
r config resetstat
|
|
|
|
|
2022-02-21 04:20:41 -05:00
|
|
|
# simple module command that replies with string error
|
Add new RM_Call flags for script mode, no writes, and error replies. (#10372)
The PR extends RM_Call with 3 new capabilities using new flags that
are given to RM_Call as part of the `fmt` argument.
It aims to assist modules that are getting a list of commands to be
executed from the user (not hard coded as part of the module logic),
think of a module that implements a new scripting language...
* `S` - Run the command in a script mode, this means that it will raise an
error if a command which are not allowed inside a script (flaged with the
`deny-script` flag) is invoked (like SHUTDOWN). In addition, on script mode,
write commands are not allowed if there is not enough good replicas (as
configured with `min-replicas-to-write`) and/or a disk error happened.
* `W` - no writes mode, Redis will reject any command that is marked with `write`
flag. Again can be useful to modules that implement a new scripting language
and wants to prevent any write commands.
* `E` - Return errors as RedisModuleCallReply. Today the errors that happened
before the command was invoked (like unknown commands or acl error) return
a NULL reply and set errno. This might be missing important information about
the failure and it is also impossible to just pass the error to the user using
RM_ReplyWithCallReply. This new flag allows you to get a RedisModuleCallReply
object with the relevant error message and treat it as if it was an error that was
raised by the command invocation.
Tests were added to verify the new code paths.
In addition small refactoring was done to share some code between modules,
scripts, and `processCommand` function:
1. `getAclErrorMessage` was added to `acl.c` to unified to log message extraction
from the acl result
2. `checkGoodReplicasStatus` was added to `replication.c` to check the status of
good replicas. It is used on `scriptVerifyWriteCommandAllow`, `RM_Call`, and
`processCommand`.
3. `writeCommandsGetDiskErrorMessage` was added to `server.c` to get the error
message on persistence failure. Again it is used on `scriptVerifyWriteCommandAllow`,
`RM_Call`, and `processCommand`.
2022-03-22 08:13:28 -04:00
|
|
|
assert_error "ERR Unknown Redis command 'hgetalllll'." {r do_rm_call hgetalllll}
|
|
|
|
assert_equal [errorrstat ERR r] {count=1}
|
2022-02-13 11:37:32 -05:00
|
|
|
|
2022-02-21 04:20:41 -05:00
|
|
|
# module command that replies with string error from bg thread
|
2022-02-13 11:37:32 -05:00
|
|
|
assert_error "NULL reply returned" {r do_bg_rm_call hgetalllll}
|
Add new RM_Call flags for script mode, no writes, and error replies. (#10372)
The PR extends RM_Call with 3 new capabilities using new flags that
are given to RM_Call as part of the `fmt` argument.
It aims to assist modules that are getting a list of commands to be
executed from the user (not hard coded as part of the module logic),
think of a module that implements a new scripting language...
* `S` - Run the command in a script mode, this means that it will raise an
error if a command which are not allowed inside a script (flaged with the
`deny-script` flag) is invoked (like SHUTDOWN). In addition, on script mode,
write commands are not allowed if there is not enough good replicas (as
configured with `min-replicas-to-write`) and/or a disk error happened.
* `W` - no writes mode, Redis will reject any command that is marked with `write`
flag. Again can be useful to modules that implement a new scripting language
and wants to prevent any write commands.
* `E` - Return errors as RedisModuleCallReply. Today the errors that happened
before the command was invoked (like unknown commands or acl error) return
a NULL reply and set errno. This might be missing important information about
the failure and it is also impossible to just pass the error to the user using
RM_ReplyWithCallReply. This new flag allows you to get a RedisModuleCallReply
object with the relevant error message and treat it as if it was an error that was
raised by the command invocation.
Tests were added to verify the new code paths.
In addition small refactoring was done to share some code between modules,
scripts, and `processCommand` function:
1. `getAclErrorMessage` was added to `acl.c` to unified to log message extraction
from the acl result
2. `checkGoodReplicasStatus` was added to `replication.c` to check the status of
good replicas. It is used on `scriptVerifyWriteCommandAllow`, `RM_Call`, and
`processCommand`.
3. `writeCommandsGetDiskErrorMessage` was added to `server.c` to get the error
message on persistence failure. Again it is used on `scriptVerifyWriteCommandAllow`,
`RM_Call`, and `processCommand`.
2022-03-22 08:13:28 -04:00
|
|
|
assert_equal [errorrstat NULL r] {count=1}
|
2022-02-13 11:37:32 -05:00
|
|
|
|
2022-02-21 04:20:41 -05:00
|
|
|
# module command that returns an arity error
|
2022-02-13 11:37:32 -05:00
|
|
|
r do_rm_call set x x
|
|
|
|
assert_error "ERR wrong number of arguments for 'do_rm_call' command" {r do_rm_call}
|
Add new RM_Call flags for script mode, no writes, and error replies. (#10372)
The PR extends RM_Call with 3 new capabilities using new flags that
are given to RM_Call as part of the `fmt` argument.
It aims to assist modules that are getting a list of commands to be
executed from the user (not hard coded as part of the module logic),
think of a module that implements a new scripting language...
* `S` - Run the command in a script mode, this means that it will raise an
error if a command which are not allowed inside a script (flaged with the
`deny-script` flag) is invoked (like SHUTDOWN). In addition, on script mode,
write commands are not allowed if there is not enough good replicas (as
configured with `min-replicas-to-write`) and/or a disk error happened.
* `W` - no writes mode, Redis will reject any command that is marked with `write`
flag. Again can be useful to modules that implement a new scripting language
and wants to prevent any write commands.
* `E` - Return errors as RedisModuleCallReply. Today the errors that happened
before the command was invoked (like unknown commands or acl error) return
a NULL reply and set errno. This might be missing important information about
the failure and it is also impossible to just pass the error to the user using
RM_ReplyWithCallReply. This new flag allows you to get a RedisModuleCallReply
object with the relevant error message and treat it as if it was an error that was
raised by the command invocation.
Tests were added to verify the new code paths.
In addition small refactoring was done to share some code between modules,
scripts, and `processCommand` function:
1. `getAclErrorMessage` was added to `acl.c` to unified to log message extraction
from the acl result
2. `checkGoodReplicasStatus` was added to `replication.c` to check the status of
good replicas. It is used on `scriptVerifyWriteCommandAllow`, `RM_Call`, and
`processCommand`.
3. `writeCommandsGetDiskErrorMessage` was added to `server.c` to get the error
message on persistence failure. Again it is used on `scriptVerifyWriteCommandAllow`,
`RM_Call`, and `processCommand`.
2022-03-22 08:13:28 -04:00
|
|
|
assert_equal [errorrstat ERR r] {count=2}
|
2022-02-13 11:37:32 -05:00
|
|
|
|
2022-02-21 04:20:41 -05:00
|
|
|
# RM_Call that propagates an error
|
2022-02-13 11:37:32 -05:00
|
|
|
assert_error "WRONGTYPE*" {r do_rm_call hgetall x}
|
|
|
|
assert_equal [errorrstat WRONGTYPE r] {count=1}
|
2022-02-21 04:20:41 -05:00
|
|
|
assert_match {*calls=1,*,rejected_calls=0,failed_calls=1} [cmdrstat hgetall r]
|
2022-02-13 11:37:32 -05:00
|
|
|
|
2022-02-21 04:20:41 -05:00
|
|
|
# RM_Call from bg thread that propagates an error
|
2022-02-13 11:37:32 -05:00
|
|
|
assert_error "WRONGTYPE*" {r do_bg_rm_call hgetall x}
|
|
|
|
assert_equal [errorrstat WRONGTYPE r] {count=2}
|
2022-02-21 04:20:41 -05:00
|
|
|
assert_match {*calls=2,*,rejected_calls=0,failed_calls=2} [cmdrstat hgetall r]
|
|
|
|
|
|
|
|
assert_equal [s total_error_replies] 5
|
|
|
|
assert_match {*calls=4,*,rejected_calls=0,failed_calls=3} [cmdrstat do_rm_call r]
|
|
|
|
assert_match {*calls=2,*,rejected_calls=0,failed_calls=2} [cmdrstat do_bg_rm_call r]
|
2022-02-13 11:37:32 -05:00
|
|
|
}
|
|
|
|
|
2022-01-23 03:05:06 -05:00
|
|
|
test "Unload the module - blockedclient" {
|
|
|
|
assert_equal {OK} [r module unload blockedclient]
|
|
|
|
}
|
2020-09-09 09:01:16 -04:00
|
|
|
}
|