Exadra37
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?
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Deploy Phoenix to your own VPS with PaaS ease: push-to-deploy, zero downtime, auto SSL, managed Postgres. 14-day free trial at potions.io
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #ai
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #blog-post
- #ecto-query
- #elixirconf-us
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Producing high quality Elixir screencasts since 2017.
**Building the future of software with AI, trust, and human connection.**
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
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.