I am stumbling at random intervals, but quite predictably every several months or so, on the issue that someone in some project created a bug, because they didn't realize at the moment that changes made in runtime.exs will be deep-merged with config.exs or prod.exs respectively.
The most recent example for me is when someone wanted to remove global_limit from our Oban engine this way:
# config/config.exs
config :core, :background_jbos, queues: [my_queue: [global_limit: 1, local_limit: 1]]
we had this in runtime.exs:
# config/runtime.exs
config :core, :background_jbos, queues: [my_queue: [global_limit: 100, local_limit: 10]]
The person changed it to:
# config/runtime.exs
config :core, :background_jbos, queues: [my_queue: [local_limit: 10]]
i.e. they removed global_limit configuration option, expecting it to lift the limit completely, instead because configs are deep-merged, it used global_lmit of 1.
Obviously everything locked up as the server is quite busy and we had tens of thousands jobs accumulating in every minute O_o.
I am raising the issue because I have seen this enough times that I am thinking a variant of config/2 function that does *not* deep merge with the existing config key, but replaces it completely could be warranted.
Obviously naming it is hard but something like Config.put_config/2 could work for me I think.
Let me know if that's useful thing to have for other people, maybe it's a singular issue that only my teams stumble upon xD