Unsafe Application configuration call Application.fetch_env!/2

Questions / Help
, ,
1

I have put some module attributes in my tests for easier reference, like this

@example Application.fetch_env!(:my_app, :thing)

but I notice I get errors when I run mix credo --strict:

Module attribute @example makes use of unsafe Application configuration call Application.fetch_env!/2

I am not understanding why this is unsafe?

1 Like
2

The value of the @example attribute will be set at compile time and cannot be changed later. This is “unsafe” because it is easy to mistakenly think that it will follow the value configured at runtime, for example in config/runtime.exs, leading to hard to track errors.

If you intend to set such a value at compile time, use Application.compile_env/3 available since Elixir 1.10.

7 Likes
3

Thank you for the explanation. I am still not sure why confusing == unsafe? This would means that many languages are “unsafe” haha. My understanding is that anything outside of a do…end block is evaluated at compile-time. But maybe this is my bad understanding – maybe Application.compile_env/3 does not works this way?

Is possible to use ENV variable to inject code that gets compiled into the module in this way? For example

export INJECT='def x(), do: IO.puts("Boom")'

and then read that into a module or something like this?

4

It’s possible but you would have to go out of your way to make it possible.

The meaning of “unsafe” here is different. The reason is that code like that can be confusing to a developer. They may expect that after they have built the application into a Mix release and transferred that to the server, that they can still change the value of the module attribute by changing the config, for example in config/runtime.exs. But because module attributes are handled at compile time, this is not possible. So they may waste a lot of time not knowing why the config is not being read, or even not notice the problem at all until it causes a bug later.

What compile_env does is store the value at compile time, but also check at startup if there is another value configured (like in config/runtime.exs). If so, it will raise an error, thus alerting the developers that they have misunderstood how the config works and that they need to correct the issue.

You can find more here: https://elixir-lang.org/blog/2020/01/27/elixir-v1-10-0-released/

2 Likes