I have an internal use-case that requires me to dynamically apply validation logic on a configuration parameter like if the previous value of the configuration is X, allow changing it to value Y, but not Z via a CONFIG SET command. Apparently in Redis 7.0, there is no easy way for me to do this. The reason is that the apply function in config.c doesn't know the previous value of the configuration, only the new value.

This was not an issue previously in Redis 6. Namely the update function in config.c takes both the previous value and the new value of the configuration parameter as arguments so it is easy to perform validations like this.

I tried to use the is_valid function which allows me to compare the previous value and the new value of the configuration, but I noticed it is also executed when the server starts up. As a result, this validation logic would validate the initial value of the configuration parameter with the server's default value which can make the server fail to start up. So this doesn't work either.

So far I can think of 2 potential solutions here:

  1. Implement a state variable that indicates if the server is in the process of starting up or not. That variable can be unset when initServer() finishes. That way the custom is_valid function can use it to perform the validation only if the server is already up.

  2. Implement the ability for the apply function to know the previous value of the configuration parameter.

Any thoughts here?

Comment From: oranagra

we did remove the prev value from the apply function to simplify things, IIRC it was so that we can easily add a mechanism of rollbacks, this was all part of the variadic config project.

i think that if you'll implement your project as a module, you won't have this problem since modules do know or actually control when they're getting a config during loading or later.

if you are inside the redis (fork) and wanna depend on some server variable to make a distinction between startup is_valid and runtime, then you have no problem adding such a server variable in your fork.

Comment From: QuChen88

I agree that there are ways I can solve this problem in our internal fork. Just raised this question to see if it is beneficial or not to add back the ability to know the previous configuration value in the apply function. IMO it can be useful in terms of doing more advanced parameter validations upon update at runtime.

Given that the previous configuration values are already saved in the config system in order to achieve rollbacks, this should not be too hard to implement.

Comment From: oranagra

at the time, i also wanted to keep the prev value as it seem handy, but IIRC the discussion in that PR indicated that it complicates the rollback mechanism (or maybe it was something else?). p.s. this may also mean that even your solution of a server variable to distinguish between startup and runtime may be problematic, not sure you'll be able to handle rollbacks and partial rollbacks correctly. note that the config mechanism first sets all the configs, and only then calls all the apply functions (a requirement we had for TLS related configs, which was the trigger for the variadic config), so that may cause some additional complications in rollbacks.

Comment From: madolson

at the time, i also wanted to keep the prev value as it seem handy, but IIRC the discussion in that PR indicated that it complicates the rollback mechanism (or maybe it was something else?).

This is my recollection as well. My guess is retaining all of the old values will be a non-trivial amount of work. I don't have strong objection to the implementation, it may be useful someday.

Another option is to have two distinct configs that are synchronized during the apply step. You have something like server.config which is connected to the config system and server.real_config which is the actual value you check. The applyFn can then check if you are allowed to transition from server.config to server.real_config, and if not throw an error.