Don't run command filter on blocked command reprocessing (#11895)

Previously we would run the module command filters even upon blocked
command reprocessing.  This could modify the command, and it's args.
This is irrelevant in the context of a command being reprocessed (it already
went through the filters), as well as breaks the crashed command lookup
that exists in the case of a reprocessed command.

fixes #11894.

Co-authored-by: Oran Agra <oran@redislabs.com>

1 files changed, 25 insertions, 0 deletions

diff --git a/tests/unit/moduleapi/commandfilter.tcl b/tests/unit/moduleapi/commandfilter.tcl
index 427609d3e..d6193b1ca 100644
--- a/tests/unit/moduleapi/commandfilter.tcl
+++ b/tests/unit/moduleapi/commandfilter.tcl
@@ -116,3 +116,28 @@ test {RM_CommandFilterArgInsert and script argv caching} {
     }
 }
 
+# previously, there was a bug that command filters would be rerun (which would cause args to swap back)
+# this test is meant to protect against that bug
+test {Blocking Commands don't run through command filter when reprocessed} {
+    start_server {tags {"modules"}} {
+        r module load $testmodule log-key 0
+
+        r del list1{t}
+        r del list2{t}
+
+        r lpush list2{t} a b c d e
+
+        set rd [redis_deferring_client]
+        # we're asking to pop from the left, but the command filter swaps the two arguments,
+        # if it didn't swap it, we would end up with e d c b a 5 (5 being the left most of the following lpush)
+        # but since we swap the arguments, we end up with 1 e d c b a (1 being the right most of it).
+        # if the command filter would run again on unblock, they would be swapped back.
+        $rd blmove list1{t} list2{t} left right 0
+        wait_for_blocked_client
+        r lpush list1{t} 1 2 3 4 5
+        # validate that we moved the correct element with the swapped args
+        assert_equal [$rd read] 1
+        # validate that we moved the correct elements to the correct side of the list
+        assert_equal [r lpop list2{t}] 1
+    }
+}