From 266d95066da8082ab569207765bea674fa297404 Mon Sep 17 00:00:00 2001
From: guybe7 <guy.benoish@redislabs.com>
Date: Tue, 28 Dec 2021 09:19:58 +0100
Subject: [PATCH] Remove incomplete fix of a broader problem (#10013)

Preventing COFIG SET maxmemory from propagating is just the tip of the iceberg.
Module that performs a write operation in a notification can cause any
command to be propagated, based on server.dirty

We need to come up with a better solution.
---
 src/config.c                       | 3 ---
 tests/unit/moduleapi/propagate.tcl | 2 ++
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/src/config.c b/src/config.c
index 129770571..407cf7249 100644
--- a/src/config.c
+++ b/src/config.c
@@ -2207,9 +2207,6 @@ static int updateMaxmemory(const char **err) {
         }
         performEvictions();
     }
-    /* The function is called via 'CONFIG SET maxmemory', we don't want to propagate it
-     * because server.dirty might have been incremented by performEvictions() */
-    preventCommandPropagation(server.current_client);
     return 1;
 }
 
diff --git a/tests/unit/moduleapi/propagate.tcl b/tests/unit/moduleapi/propagate.tcl
index 6d9b5bdde..edeb23531 100644
--- a/tests/unit/moduleapi/propagate.tcl
+++ b/tests/unit/moduleapi/propagate.tcl
@@ -174,6 +174,7 @@ tags "modules" {
 
                     # Note whenever there's double notification: SET with EX issues two separate
                     # notifications: one for "set" and one for "expire"
+                    # "config set" should not be here, see https://github.com/redis/redis/issues/10014
                     assert_replication_stream $repl {
                         {select *}
                         {multi}
@@ -197,6 +198,7 @@ tags "modules" {
                         {del asdf*}
                         {incr notifications}
                         {del asdf*}
+                        {config set maxmemory 1}
                         {multi}
                         {incr notifications}
                         {set asdf4 4}