Template not compiling, but I can see it in the correct directory. It's *right there*

I’ve added a new route for my Page Controller to handle.

get "/reaper-u", PageController, :reaper_u

The requisite handler is in the PageController:

def reaper_u(conn, _params) do
    render(conn, "reaper_u.html")

The file is right there with all the other template files for this view.

Screenshot 2022-02-03 at 22.35.25

When I renamed the file to try to shake something loose, I saw the following response in iex, so Phoenix Live Reload appears to be tracking the file.

[debug] Live reload: lib/reapercon_web/templates/page/reaper_u.html.eex

It’s all really vanilla stuff. The template only has a h2 block in it.

 Phoenix.Template.UndefinedError at GET /reaper-u
Could not render "reaper_u.html" for ReaperconWeb.PageView, please define a matching clause for render/2 or define a template at "lib/reapercon_web/templates/page/*". The following templates were compiled:

* conduct.html
* costume_contest.html
* events.html
* exhibitors.html
* faq.html
* index.html
* merch.html
* schedule.html
* venue.html
* wraithking.html

In my rage and desperation, I cleared out my mix deps and rebuilt all of them. (mix deps.clean --all; mix deps.get) No dice.

Finally, I shut down my local instance, rm -fr _build from the directory root, and started the server again. Now it works. Template compiles, I can continue working.

To test, I add another template, route, etc. The template will not compile on its own. I have to delete _build and everything is fine.

It seems to me that deleting the _build directory to get a template to compile is a little extreme, but here we are.

It appears that the template compilation is stuck somehow, refusing to see the new file, and not updating until I take a hammer to the _build directory. Is there something I’m missing that would cause this to happen? I hope the solution ends up being crushingly and embarrassingly obvious, but I can’t see it.

1 Like

Seems strange. I’d consider this:

  • Would mix compile --force fix the problem?
  • Are you maybe running another instance of the server somewhere in the background?
  • Are you developing in Docker?
  • Does updating Elixir and deps to the latest version solve the problem?

Thanks for the feedback!

  1. Stopping the instance, running mix compile --force, and restarting the server works.
  2. No other instances running.
  3. Not Docker.
  4. Running latest Elixir and latest deps relevant to my project.
1 Like

That seems to narrow down the issue a bit, although I’m not sure what are the next steps to debug this. I’d make sure there are no zombie processes with something like ps. If there’s nothing showing up, I’d try to narrow it down even more. Would adding this work?

# In the controller
def reaper_u(conn, _params) do
  Phoenix.Controller.html(conn, "<html>...</html>")

If so, would this work:

# In the view:
def render("reaper_u.html", _assigns) do
  # I think we need to call raw here

Yeah I think I’ve noticed that issue also. Are you able to reproduce it reliably?

I am not able to consistently recreate this at this time. You’re on the ElixirLS core team? What an amusing coincidence.

As all this was going down, I was on the road on my M1 MacBook Air. My battery life was simply awful – I hit 50% from a full charge within an hour. The computer was reporting that VSCode was using significant energy, and I could immediately tell – the Air was actually getting hot. Something was pegging the CPU.

Restarting VSCode, looking at the output tab in its terminal, ElixirLS was restarting infinitely. “Done writing manifest in 843 milliseconds” and then all over again.

It’s clear by now that this is a me problem. Time to start from zero.

I committed my recent changes, deleted the project directory, went into ASDF, removed and rebuilt my erlang/elixir environment, checked out a fresh copy of my project, reinstalled all the deps, started looking at the logs.

ElixirLS is no longer endlessly re-indexing. My templates are updating in real-time.

I cannot replicate this, but I suspect all my problems were a result of some mismatch of built components that weren’t living in harmony.

Lesson learned: if my elixir project is acting consistently strange, checking it back out from the repo and rebuilding it from scratch can be a valid troubleshooting step.

I still got a boom alias that will rm - rf the _build/dev/lib/my_app to force a clean compilation for when bizarre things like your case happens.

Truth be told though, after elixir 1.12, I didn’t have to hit that alias yet.

I’m hitting this issue as well. Running inside WSL, though. mix compile --force helps.

Erlang/OTP 25 [erts-13.1.2] [source] [64-bit] [smp:32:32] [ds:32:32:10] [async-threads:1] [jit:ns]

Elixir 1.14.1 (compiled with Erlang/OTP 25)

Creating a new controller, view and a template reproduces the issue for me.

Also I’ve tried to reproduce this issue on my Mac (running the same Elixir/Phoenix version) and it’s working fine for me there.

Nevermind, reproduced it on my Mac as well. :frowning:

Seems like I’ve found the reproduction steps:

  1. Create a controller
  2. Create a view
  3. Create a template

These steps lead to a broken controller.

However, if I do it like this (order of 2 and 3 can be swapped):

  1. Create a template
  2. Create a view
  3. Create a controller

Everything works fine.

I assume Phoenix somehow inline the render(conn, "index.html") and since the file does not exist at the compilation moment (when Live reload recompiles the app), it always yields an error unless you do a forced compilation.

1 Like

Also, for what it’s worth, I’m unable to reproduce it on Phoenix v1.7-dev using embed_templates and the new :html component. :person_shrugging:

Hit this issue following the tutorial, just like wktdev describes in this other topic. Running mix compile --force fixes it.

1 Like

Same issue with me, using Ubuntu and following the tutorial. Like @davidag, running mix compile --force works.

1 Like

davidag and code-anth, that’s good information. I’ll add that to the troubleshooting workflow if this ever comes up again.

1 Like

I think I came across this issue in Phoenix 1.7, and, if I remember correctly, moving the template folder to a different location and back again using the VS Code file explorer resulted in success.