2022-04-17 08:43:22 -04:00
|
|
|
set testmodule [file normalize tests/modules/publish.so]
|
|
|
|
|
|
|
|
start_server {tags {"modules"}} {
|
|
|
|
r module load $testmodule
|
|
|
|
|
|
|
|
test {PUBLISH and SPUBLISH via a module} {
|
|
|
|
set rd1 [redis_deferring_client]
|
|
|
|
set rd2 [redis_deferring_client]
|
|
|
|
|
|
|
|
assert_equal {1} [ssubscribe $rd1 {chan1}]
|
|
|
|
assert_equal {1} [subscribe $rd2 {chan1}]
|
|
|
|
assert_equal 1 [r publish.shard chan1 hello]
|
|
|
|
assert_equal 1 [r publish.classic chan1 world]
|
2022-05-31 01:03:59 -04:00
|
|
|
assert_equal {smessage chan1 hello} [$rd1 read]
|
2022-04-17 08:43:22 -04:00
|
|
|
assert_equal {message chan1 world} [$rd2 read]
|
Fix broken protocol when PUBLISH emits local push inside MULTI (#12326)
When a connection that's subscribe to a channel emits PUBLISH inside MULTI-EXEC,
the push notification messes up the EXEC response.
e.g. MULTI, PING, PUSH foo bar, PING, EXEC
the EXEC's response will contain: PONG, {message foo bar}, 1. and the second PONG
will be delivered outside the EXEC's response.
Additionally, this PR changes the order of responses in case of a plain PUBLISH (when
the current client also subscribed to it), by delivering the push after the command's
response instead of before it.
This also affects modules calling RM_PublishMessage in a similar way, so that we don't
run the risk of getting that push mixed together with the module command's response.
2023-06-20 13:41:41 -04:00
|
|
|
$rd1 close
|
|
|
|
$rd2 close
|
2022-04-17 08:43:22 -04:00
|
|
|
}
|
Fix broken protocol when PUBLISH emits local push inside MULTI (#12326)
When a connection that's subscribe to a channel emits PUBLISH inside MULTI-EXEC,
the push notification messes up the EXEC response.
e.g. MULTI, PING, PUSH foo bar, PING, EXEC
the EXEC's response will contain: PONG, {message foo bar}, 1. and the second PONG
will be delivered outside the EXEC's response.
Additionally, this PR changes the order of responses in case of a plain PUBLISH (when
the current client also subscribed to it), by delivering the push after the command's
response instead of before it.
This also affects modules calling RM_PublishMessage in a similar way, so that we don't
run the risk of getting that push mixed together with the module command's response.
2023-06-20 13:41:41 -04:00
|
|
|
|
|
|
|
test {module publish to self with multi message} {
|
|
|
|
r hello 3
|
|
|
|
r subscribe foo
|
|
|
|
|
|
|
|
# published message comes after the response of the command that issued it.
|
|
|
|
assert_equal [r publish.classic_multi foo bar vaz] {1 1}
|
|
|
|
assert_equal [r read] {message foo bar}
|
|
|
|
assert_equal [r read] {message foo vaz}
|
|
|
|
|
|
|
|
r unsubscribe foo
|
|
|
|
r hello 2
|
|
|
|
set _ ""
|
|
|
|
} {} {resp3}
|
|
|
|
|
2022-04-17 08:43:22 -04:00
|
|
|
}
|