for some time now we are facing a strange problem - we basically cannot run
iex -S mix and
mix phx.server at the same time as each of them forces recompilation of the whole project even if no change happened in between.
I believe this happened after we migrated from an umbrella to standard structure, but I can’t be certain.
The order of the commands does not matter. Every time we run
iex -S mix after
mix phx.server it recompiles the whole project and the running server becomes unusable due to that (and vice-versa). See the attached screenshot, please.
I tested newly generated Phoenix application and it does not happen there.
I was thinking it might be caused by some compile-time configuration but I have no idea which one that could be and why it would be different between iex and mix.
Any idea on what to check?
Elixir: 1.14.5/OTP 26
All packages up-to date.
iex -S mix phx.server does not cause any recompilation
I found the issue
I think it’s time to change the field…my brain must have been melted to not see the problem with this in the first place
Wow, quite the interesting bug.
It is interesting what you wanted to try to achieve by putting
compiled_at in the config?
Man, why is
compiled_at even there? I see it for the first time ever, never needed it.
When you are an admin user in our platform you can see a small section in the navigation menu with information about the “version”. This helps us to see what specific commit, branch and Docker image’s “build time” is deployed.
It also helps to see if the request ended on a server with an older build or not as the deployment of a new image might be a bit random across all servers behind a load balancer (but that’s not the main feature).
The time is there more for user friendliness and quick glance than anything else - as the commit hash is a bit more involved to find and relate to.
This can be definitely designed better than with DateTime.utc_now() in a compile-time config file
I still don’t understand why it touches
config.exs again between
iex -S mix and
mix phx.server when it was compiled already.
I “feel” like this was changed somewhat recently (in the last 6 months) as I don’t remember this being an issue in older versions of Elixir. But I might be wrong.
We have this particular line there for a year at this point.
The idea is clear, the execution is very questionable, partly because compilation of the project should be outside of application scope.
I would recommend to switch to an environment variable generated by your build system.
I definitely agree with that. You know how it is with long forgotten quick and dirty hacks…they usually bite you down the road
The recompilation watcher is part of phoenix framework as far as I remember, it was refactored a couple of times so this is nothing new. In this case, re-triggering compilation is a correct behavior, as the value changes always at compile-time, the only sad thing is that it doesn’t show a warning.
When using credo do you get any warnings when doing this kind of config?