Phoenix server is delivering default HTML instead of requested JS files

For some reason it matches your page controllers index route. Could you please show us the output of mix phx.routes, the actual definitions from the routes.ex file and also in your endpoint.ex the line(s) starting with plug Plug.Static?

I’m not sure yet if this matters, but have you built the application inside of that centos container or on the mac os?

You shouldn’t mix and match modules compiled on different OS and/or arches. Try to always compile your application on a system that is as close as possible to the deploy target.

Thanks for the quick reply!

Output from mix phx.routes:

phoenix_1   |            *    /api/graphiql  Absinthe.Plug.GraphiQL [schema: MyApp.Schema, interface: :simple]
phoenix_1   |            *    /api           Absinthe.Plug [schema: MyApp.Schema]
phoenix_1   | page_path  GET  /*path         MyApp.PageController :index

This is router.ex (I don’t have a routes.ex so guessing that’s what you meant?

defmodule MyApp.UtilityRouter do
  use Plug.Router

  plug :match
  plug :dispatch

  get "/alive" do
    send_resp(conn, 200, "ok")
  end
end

defmodule MyApp.Router do
  use MyApp.Web, :router

  pipeline :browser do
    plug :accepts, ["html"]
    plug :fetch_session
    plug :fetch_flash
    plug :protect_from_forgery
    plug :put_secure_browser_headers
  end

  pipeline :api do
    plug :accepts, ["json"]
  end

  scope "/api" do
    pipe_through :api

    if Mix.env === :dev do
      forward "/graphiql", Absinthe.Plug.GraphiQL,
      schema: MyApp.Schema,
      interface: :simple
    end

    forward "/", Absinthe.Plug,
      schema: MyApp.Schema
  end

  scope "/", MyApp do
    pipe_through :browser

    forward "/utility", UtilityRouter

    get("/*path", PageController, :index)
  end
end

endpoint.ex:

plug Plug.Static,
    at: "/", from: :myapp, gzip: false,
    only: ~w(css fonts images js favicon.ico robots.txt)

It’s being built within the container itself (until I get a local build slave to build a full deployment package) as part of the docker-compose like:

mix archive.install phx_1.6.ez --force
mix local.hex --force
mix deps.get --force
mix local.rebar --force
mix phx.digest

Then the docker run command is mix phx.server.

Is plug static before or after your router plug?

What is phx_1.6?

Why are you installing rebar after building your deps? You probably won’t need it anymore by then.

Static is before my router.

phx_1.6 is I believe a poorly named elixir 1.6 install.

It looks like that may have been left over from something else - I’m going to play the noob card again here…

Installing that archive is very suspicious, especially as you have no clue what it does.

But before digging further into your docker container… Does it work locally when running mix phx.server?

I’ve checked - the archive is Elixir 1.6 - that is Docker’s standard base image.

Nothing is installed on the CentOS box , everything runs through the Docker container. Do you think it would be worth installing Elixir directly on the CentOS box and trying it there? Is that a relevant test?

When I run locally on OSX using mix phx.server, everything runs as expected.

But why are you archive.installing it then?

Looks like some confusion with the guy who put the Docker container together - didn’t realise that deps.get would install Phoenix - that image was Elixir 1.6 with Phoenix.

That line has now been removed.

Are the resources being served correctly without digesting?
As I understood you are trying to serve a SPA from the PageController thus the path /*path will match anything that was not prior matched. If the resources are being served correctly without digesting then you might need to configure the Static plug to handle the folders where the digested files are sent. (I can’t remember if they are the same, I have been months without Elixir)

@joaoevangelista thanks for the suggestion - sent me off down the path of serving static files and came across this thread Static files not found where the OP was referencing files which didn’t actually exist.

My issue was that in app.html.eex I was using MYApp.prod.app.js yet the actual file being produced was MyApp.prod.app.js. OSX is more forgiving than CentOS when it comes to such things.

@NobbZ thanks for your help as well

Sorry for wasting time! Hopefully this helps someone else in the same scenario, though - even if the filenames seem correct, double, no triple check!