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?

14 comments

/phoenix #troubleshooting #libraries

27 1724 14

2021-05-05 22:37:04 UTC

Marked As Solved

josevalim

Creator of Elixir

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.

Post #7

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.

Post #15

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.

Post #9

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.

Post #10