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:
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?
Trending in Questions
Hello!
Suppose you are building workflow (order / task / payment) processing system with the following requirements:
Each workflow con...
New
I’m in search of an Elixir library that offers PDF generation capabilities similar to Ruby’s Prawn. While there have been discussions abo...
New
I’m looking to build a personal workflow to quickly deploy web applications written in elixir/phoenix, for local consumption (ie not on t...
New
Using Phoenix.LiveView.TagEngine as an EEx.Engine is deprecated!
To compile HEEx, use Phoenix.LiveView.TagEngine.compile/2 instead.
Sta...
New
Before I dive in myself, did anyone successfully sprinkle Hologram into their existing LiveView app?
Looking for hints regarding:
Addi...
New
Hi all, I wanted to ask how the community is dealing with post-release steps.
Today we have Ecto migrations, which make sure that the db...
New
I am using Oban and occasionally, shortly after a deployment, a handful of jobs can fail because of dependency on other parts of the syst...
New
Other Trending Topics
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Hello everyone. After busy few months I am happy to announce v0.1.0 of Emerge & Solve.
They are GUI (Emerge) and State management (S...
New
Emily is an Elixir library that runs Nx computations on Apple’s MLX. Install it as the default Nx backend and Nx, defn, Axon, Nx.Serving,...
New
I just stumbled on a newly redesigned elixir-lang.org. :tada: It looks like @Software_Mansion did the work, and I think it is generally a...
New
@hugobarauna and I (Alex Koutmos) have been hard at work on writing a book on Nerves that takes you from simply blinking LEDs to building...
New
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Develop your skills with books, videos, and courses.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #hex
- #performance
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.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Develop your skills with books, videos, and courses.
Producing high quality Elixir screencasts since 2017.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
First 10 of 14 Posts
Exadra37
I discovered the function
ModuleName.module_infoand running it in my development setup and production release yields this results:Production
Module
TypeIt.Progress:Module
NaiveDateTime:Development
Module
TypeIt.Progress:Module
NaiveDateTime:The Difference
Module
TypeIt.Progress:Module
NaiveDateTime:The
+are for the development output. The differences in theexportsseem to be only due to the order of the output from running the command in production and development.I can observe that in other modules that I try
module_infoon I always get thecompileinfo in development, but not in production.So, I don’t see anything here that reveals a potential issue. Even the
vsnandmd5are exactly the same between production and development.I am really lost in how to debug this issue
amnu3387
I imagine you don’t have mix in the prod env, or you’re not including it?
josevalim
Hi @amnu3387 is on the right direction. I can confirm this is a bug and the root cause is that the application tracer used by Mix is not available in production and it should not be required either.
I need a small app that reproduces the error to understand if this is a Mix bug or a library/application bug. Given the fact it is expanding compilation code at runtime, I am more inclined to think it is the latter.
Exadra37
I feel stupid now… I completely forgot that Mix is only available in development or when compiling the release.
Totally makes sense.
I will work on one.
The library being used is Domo and I am also inclined to be a bug on it, and that was the reason I open first an issue in Github.
Exadra37
@josevalim here it is the proof of concept for the bug:
https://github.com/Exadra37/elixir-library-domo-bug
josevalim
I assume the issue is around this line:
https://github.com/IvanRublev/Domo/blob/master/lib/domo/type_checker_generator.ex#L128
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.
Exadra37
Many thanks for your time on this Jose. I really appreciate that you have jumped on
I will add your info to the Github issue, and see what @IvanR as to say.
Having the creator of the language interacting with us to help in issues or just discussions was one of the main drivers to make me stick around this forum, and by extension in Elixir
IvanR
Many thanks for noticing this. I’m working on the version that expands types within a given environment at the compile-time only.
I intend to mark this lib as not production-ready till then.
@Exadra37 Let’s see what can be done, I’ll give an update on the GitHub issue.
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/1function comes at the cost of 1.2-1.5x slower operation comparing withstruct!/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:
So they are tagged as runtime expansions.