Exadra37
Production Error: Function Mix.Compilers.ApplicationTracer.trace/2 is undefined
In a nutshell I have an error in production that I don’t have in development while using the same versions for all the software involved.
Environment
- Elixir version (elixir -v):
$ ./bin/tasks remote
Erlang/OTP 23 [erts-11.1.6] [source] [64-bit] [smp:1:1] [ds:1:1:10] [async-threads:1]
Interactive Elixir (1.11.3) - press Ctrl+C to exit (type h() ENTER for help)
- Domo version (mix deps | grep domo | head -1):
$ mix deps | grep domo | head -1
* domo 1.0.1 (Hex package) (mix)
- TypedStruct version (mix deps | grep typed_struct | head -1):
$ mix deps | grep typed_struct | head -1
* typed_struct 0.2.1 (Hex package) (mix)
I run it in development and in production with the docker image from the Phoenix releases docs:
https://hexdocs.pm/phoenix/releases.html#containers
Versions used to build the docker image:
ELIXIR_VERSION=1.11.3
ERLANG_OTP_VERSION=23.2.2
ALPINE_VERSION=3.12.1
Actual behavior
The error from a production release:
09:20:32.459 | error | module=gen_server function=error_info/7 line=943 | GenServer #PID<0.2551.0> terminating
app_1 | ** (UndefinedFunctionError) function Mix.Compilers.ApplicationTracer.trace/2 is undefined (module Mix.Compilers.ApplicationTracer is not available)
app_1 | Mix.Compilers.ApplicationTracer.trace({:alias_reference, [line: 45], NaiveDateTime}, #Macro.Env<aliases: [], context: nil, context_modules: [TypeIt.Progress], file: "/app/lib/type_it/lib/progress.ex", function: nil, functions: [{Kernel, [!=: 2, !==: 2, *: 2, ...]}], lexical_tracker: #PID<3.316.0>, line: 42, macro_aliases: [], macros: [{Domo, ...}, {...}], module: TypeIt.Progress, requires: [...], ...>)
app_1 | (elixir 1.11.3) src/elixir_env.erl:36: :elixir_env."-trace/2-lc$^0/1-0-"/3
app_1 | (elixir 1.11.3) src/elixir_env.erl:36: :elixir_env.trace/2
app_1 | (elixir 1.11.3) lib/macro.ex:1440: Macro.do_expand_once/2
app_1 | (elixir 1.11.3) lib/macro.ex:1610: Macro.expand_until/2
app_1 | (domo 1.0.1) lib/domo/type_spec_matchable/remote_type.ex:11: Domo.TypeSpecMatchable.RemoteType.expand/2
app_1 | (domo 1.0.1) lib/domo/type_contract.ex:642: Domo.TypeSpecMatchable.Any.match_spec?/3
app_1 | (tasks 0.1.0) lib/type_it/lib/progress.ex:42: TypeIt.Progress.TypeChecker.__field_error/1
The Typed Struct code:
defmodule TypeIt.Progress do
use Domo
@all_states %{
backlog: "Backlog",
todo: "Todo",
doing: "Doing",
pending: "Pending",
done: "Done",
archived: "Archived",
}
@states Map.keys(@all_states)
typedstruct do
field :state, :backlog | :todo | :doing | :pending | :done | :archived
field :title, String.t()
field :since, NaiveDateTime.t()
end
def default(), do: new_for!(:todo)
def next_state(:backlog), do: :todo
def next_state(:todo), do: :done
def next_state(:done), do: :todo
def new_for!(state), do: new!(state: state, title: @all_states[state], since: NaiveDateTime.utc_now())
def new_for!(state, since: since), do: new!(state: state, title: @all_states[state], since: since)
def new_for!(state, title: title), do: new!(state: state, title: title, since: NaiveDateTime.utc_now())
def states() do
@states
end
def all() do
@all_states
end
end
Expected behavior
In production is throwing the reported error that crashes the app, but in development it works ok.
Summary
Looking to this line in the logs:
Mix.Compilers.ApplicationTracer.trace({:alias_reference, [line: 45], NaiveDateTime},
It seems the error is related with using:
field :since, NaiveDateTime.t()
but I don’t get why I don’t have the same error in development, when using the same exact versions of Elixir, Phoenix, OTP, and Domo library 
Any ideas?
Marked As Solved
josevalim
I assume the issue is around this line:
It is trying to save a compilation environment to use it to expand things at runtime. Not only this slow, it won’t work as you noticed. 
They should do whatever expansion they need at compile time and remove the runtime expand calls.
Also Liked
IvanR
In Domo 1.2.2 there is a verification that a struct built at compile time matches its type. That works as the last step of compilation with the library’s custom compile task 
The verification works for given modules as follows:
defmodule Planet.Bar do
use Domo
defstruct [:name]
@type t :: %__MODULE__{name: String.t()}
end
defmodule Foo do
use Domo
alias Planet.Bar
@default_name :coyote
defstruct [bar: Bar.new(name: @default_name)]
@type t :: %__MODULE__{bar: Bar.t()}
end
➜ ~ mix compile
Compiling 1 file (.ex)
Domo is compiling type ensurer for 2 modules (.ex)
== Compilation error in file lib/foo_bar.ex:15 ==
** Failed to build Planet.Bar struct.
Invalid value :coyote for field :name. Expected the value matching the <<::*8>> type.
➜ ~ echo $?
1
And with:
@default_name "Coyote"
➜ ~ mix compile
Compiling 1 file (.ex)
Domo is compiling type ensurer for 2 modules (.ex)
➜ ~ echo $?
0
There is no Macro expansion during the Foo and Bar modules compilation with Elixir. Their environments are temporary stored for the :domo_compiler step. During the Domo compiler step, the expansion works like Macro.expand_once(Bar, foo_env) to get the full name of the Planet.Bar module. Then type ensurer modules code is generated and compiled, and Bar fields stored from the new call are ensured to match the type. Then Domo compiler step drops environments and compilation finishes.
It seems that it shouldn’t be additional compile/runtime dependencies for Foo and Bar modules with the process described above 
P.S. At the application’s runtime, Foo.new/1 and Bar.new/1 ensures that input fields match the type themselves or raises on mismatch.
IvanR
IvanR
The version 1.2.0 of the Domo library is released. It resolves types and generates struct specific validation code at compile time only. It was in development for a couple of months, and it seems this is a good time for the release
This version obviously increases project compilation times that is a matter for further evaluation and optimization. It’d be nice to get feedback about compilation time changes.
Ensuring that the structure’s value matches the type with generated new/1 function comes at the cost of 1.2-1.5x slower operation comparing with struct!/1. Depending on the level of nestedness of structure types in each other and whether there are fields with lists, and how long they are.
At the same time, that can be ok for various business applications.
josevalim
One thing you will also want to consider is that, depending on how you expand, you may end-up adding compile time dependencies to the referenced modules. Which will be much more impactful to compilation times than the time spent spending.
If you really don’t use those values at compile-time, then you should do this when expanding them:
Macro.expand(alias, %{function: {:new!, 1}})
So they are tagged as runtime expansions.
amnu3387
I imagine you don’t have mix in the prod env, or you’re not including it?
Popular in Questions
Other popular topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Develop your skills with books, videos, and courses.
Categories:
Sub Categories:
Forums
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Practical resources that improve the lives of professional developers.
Producing high quality Elixir screencasts since 2017.
Enabling companies to succeed by building software people love.
Courses that'll move you from confusion to "Aha, now I get it!"