Fix an issue when module decides to unblock a client which is blocked on keys (#11832)

Currently (starting at #11012) When a module is blocked on keys it sets the
CLIENT_PENDING_COMMAND flag.
However in case the module decides to unblock the client not via the regular flow
(eg timeout, key signal or CLIENT UNBLOCK command) it will attempt to reprocess the
module command and potentially blocked again.

This fix remove the CLIENT_PENDING_COMMAND flag in case blockedForKeys is
issued from module context.

1 files changed, 17 insertions, 0 deletions

diff --git a/tests/unit/moduleapi/blockonkeys.tcl b/tests/unit/moduleapi/blockonkeys.tcl
index 85faa7525..8e095e351 100644
--- a/tests/unit/moduleapi/blockonkeys.tcl
+++ b/tests/unit/moduleapi/blockonkeys.tcl
@@ -286,4 +286,21 @@ start_server {tags {"modules"}} {
         assert_equal {gg ff ee dd cc} [$rd read]
         $rd close
     }
+    
+    test {Module explicit unblock when blocked on keys} {
+        r del k
+        r set somekey someval
+        # Module client blocks to pop 5 elements from list
+        set rd [redis_deferring_client]
+        $rd blockonkeys.blpopn_or_unblock k 5 0
+        wait_for_blocked_clients_count 1
+        # will now cause the module to trigger pop but instead will unblock the client from the reply_callback
+        r lpush k dd
+        # we should still get unblocked as the command should not reprocess
+        wait_for_blocked_clients_count 0
+        assert_equal {Action aborted} [$rd read]
+        $rd get somekey
+        assert_equal {someval} [$rd read]
+        $rd close
+    }
 }