Full Project Recompilation on Elixir 1.19 — How Can I Investigate the Root Cause?

nallwhy · December 10, 2025, 12:11am

Hi everyone,

I’m currently running into a strange full recompilation issue on Elixir 1.19 and I’d like some advice on how to further investigate the root cause.

Environment

Erlang/OTP 28.2
Elixir 1.19.4 (and all other 1.19.x versions show the same behavior)
Phoenix + Phoenix LiveView
Ash Framework
phoenix_live_reload enabled

Issue

Whenever any pattern exists under the phoenix_live_reload configuration, the following happens:

Start the server with mix phx.server.
Visit the web page.
As soon as the request hits the server, the entire project recompiles.

After that, the server works normally.

But if I stop it and run mix phx.server again, the same full recompilation occurs on the next request.

This cycle repeats every time.

If I remove all patterns from live_reload, the issue disappears — but of course that disables LiveReload entirely.

What I’ve found so far

We’ve tracked the trigger point to the following part of the Phoenix code reloader:

github.com/phoenixframework/phoenix

lib/phoenix/code_reloader/server.ex

07fc5ac21


      
            diagnostics = diagnostics ++ new_diagnostics
          
            case new_status do
              :error -> {:error, diagnostics}
              :ok -> run_compilers(rest, args, :ok, diagnostics)
              :noop -> run_compilers(rest, args, status, diagnostics)
            end
          end
          
          defp run_compiler(compiler, args) do
            result = normalize(Mix.Task.run("compile.#{compiler}", args), compiler)
            Enum.reduce(Mix.ProjectStack.pop_after_compiler(compiler), result, & &1.(&2))
          end
          
          defp normalize(result, name) do
            case result do
              {status, diagnostics} when status in [:ok, :noop, :error] and is_list(diagnostics) ->
                {status, diagnostics}
          
              # ok/noop can come from tasks that have already run
              _ when result in [:ok, :noop] ->

Something within this flow is causing the compiler to think all modules are stale, but we haven’t been able to determine why this happens specifically on Elixir 1.19.

Questions

I’d appreciate any advice on how to further approach this problem:

How can I inspect what Mix thinks has changed?

(module timestamps, manifests, dependency graph diffs, etc.)
Is there a good way to trace which module is being marked as stale first?
Any recommended debugging flags or instrumentation for Mix or the Phoenix code reloader?

If anyone has encountered similar behavior in Elixir 1.19 — or knows how to dig deeper into the compiler’s staleness detection — I’d really appreciate your insights.

Thanks in advance!

vanderhoop · December 10, 2025, 3:07am

I’ve also been running into full recompilations on 1.19 in my phoenix app, and I’ve been suspecting that there were different elixir versions on my system (I’m using mise for language version management), but I’ve made sure that the global mise elixir and erlang versions align with my project’s version, but it still happens, but when I least want/expect it. My next suspicion is that it has something to do with running LSPs during development, in my case elixir-ls and refactorex, both via VSCode, but I haven’t been able to consistently reproduce the issue, so that’s just a suspicion at this point.

jechol · December 10, 2025, 8:25am

If you’re using Kino, this may be related.

I just merged a fix for a related issue here — it was merged very recently:
https://github.com/elixir-lang/elixir/pull/15007