With the implementation of
RFC-607, we have a way of deprecating Config fields, which is very useful. However, there is an unintended side-effect in the current implementation.
Currently, the implementation is straightforward, simply adding deprecated= to the config Field. Then a python warning is thrown when you try to set the deprecated config field on the command line or in a config .py file.
When you run a task with an updated config that properly avoids the deprecated field so that no warning is thrown, the task will still persist the config with all fields – including the deprecated field. Helpfully, the persisted config will have the deprecation warning in the comment. However, if you use this persisted config file as an input to a new run, then you suddenly get a deprecation warning. This is unexpected because the user never explicitly set the deprecated config parameter.
Unfortunately, a fully general solution to this problem is difficult because of the ambiguity of whether a deprecated Field is now completely ignored under all circumstances, or will be ignored if a new replacement Field is set.
This RFC proposes a simple solution that will likely cover most cases. Specifically, if a config Field is deprecated and is equal to the default value (or otherwise unset in the case of optional config Field s) then it will not be persisted.