loadconfig not clearing application env

[lukaszsamson]

Elixir and Erlang/OTP versions

Erlang/OTP 25 [erts-13.2.2.4] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1]

Elixir 1.16.0 (compiled with Erlang/OTP 25)

Operating system

macOS

Current behavior

When loadconfig is called repeatedly it merges application configs instead of overwriting.
Repro:

1. create an empty mix app
2. add config/config.exs
3. add to config

config :logger, foo: 1

4. in iex run

Mix.start()
Code.compile_file("mix.exs")
Mix.Task.run("loadconfig")
[
  logger: [foo: 1]
]
Application.get_env(:logger, :foo)         
1

5. rename :foo to :bar

Mix.Task.run("loadconfig")
[
  logger: [bar: 1]
]
Application.get_env(:logger, :bar)         
1

6. Verify that old key is still in app env

Application.get_env(:logger, :foo)         
1

Originally reported in https://elixirforum.com/t/how-can-i-prevent-the-lsp-from-invoking-my-custom-mix-compiler/59802/6 and followed up in elixir-lsp/elixir-ls#1030

Expected behavior

I'm not sure this is a bug but there is no mention of this behavior in https://hexdocs.pm/mix/1.16.0/Mix.Tasks.Loadconfig.html. This comment states thet the configs are not deep merged

elixir/lib/mix/lib/mix/tasks/loadconfig.ex

Line 52 in 38ddc98

# Loads compile-time configuration, they support imports, and are not deep merged.

[josevalim]

I will improve the docs but the behavior you see is correct. The deep merging is only within an application. We don’t erase previously defined application keys, regardless of how they were set.

[josevalim]

In your case, you may need to delete all application keys from the environment with persistent: true using https://www.erlang.org/doc/man/application#unset_env-2. Then when you call load_config again and load the applications, you go back to the original state.

But this brings up back to previous conversations, where I think it is better to separate the LS runtime from the application runtime. Then to restart the application, you boot a new runtime. It is the best way to guarantee there is no state carried across. Because if you revert the application environment, you revert the supervision trees, people can always change the application environment directly, start named processes outside of supervision trees, etc.