Dialyxir error when using `Ecto.Query.t` as function argument

Greetings. I have a problem with dialyxir (0.5, elixir 1.5).
The usecase is this:

from(x in SomeModule)
|> function1()
|> function2()
|> limit(10)
|> function3()

I want to give the functions @specs, but here’s the problem:
@spec function1(Ecto.Query.t) :: Ecto.Query.t raises a dialyzer error:

The call 'Elixir.Pop.Search':add_tag_filters(#{'__struct__':='Elixir.Ecto.Query', 'assocs':=[], 'distinct':='nil', 'from':={'nil' | <<_:64>> | ['author' | 'author_id' | 'contents' | 'id' | 'inserted_at' | 'is_disabled' | 'is_pending' | 'l10n' | 'search'
 | 'tag_ids' | 'type' | 'updated_at' | {'inserted_at',{'Elixir.Ecto.Schema','__timestamps__',[any(),...]}} | {'updated_at',{'Elixir.Ecto.Schema','__timestamps__',[any(),...]}}] | 130233438 | {'id','id'} | #{'__struct__'=>'Elixir.Ecto.Query', 'assocs'=>[], 'author_id'=>'id', 'contents
'=>'map', 'distinct'=>'nil', 'from'=>{<<_:64>>,'Elixir.Pop.Library.Resource'}, 'group_bys'=>[], 'havings'=>[], 'id'=>'id', 'inserted_at'=>'utc_datetime', 'is_disabled'=>'boolean', 'is_pending'=>'boolean', 'joins'=>[], 'l10n'=>{'array','map'}, 'limit'=>'nil', 'lock'=>'nil', 'offset'=>
'nil', 'order_bys'=>[], 'prefix'=>'nil', 'preloads'=>[], 'search'=>'map', 'select'=>'nil', 'sources'=>'nil', 'tag_ids'=>{'array','integer'}, 'type'=>'string', 'updated_at'=>'utc_datetime', 'updates'=>[], 'wheres'=>[]},'Elixir.Pop.Library.Resource'}, 'group_bys':=[], 'havings':=[], 'j
oins':=[], 'limit':='nil', 'lock':='nil', 'offset':='nil', 'order_bys':=[], 'prefix':='nil' | <<_:64>> | ['author' | 'author_id' | 'contents' | 'id' | 'inserted_at' | 'is_disabled' | 'is_pending' | 'l10n' | 'search' | 'tag_ids' | 'type' | 'updated_at' | {'inserted_at',{'Elixir.Ecto.S
chema','__timestamps__',[any(),...]}} | {'updated_at',{'Elixir.Ecto.Schema','__timestamps__',[any(),...]}}] | 130233438 | {'id','id'} | #{'__struct__'=>'Elixir.Ecto.Query', 'assocs'=>[], 'author_id'=>'id', 'contents'=>'map', 'distinct'=>'nil', 'from'=>{<<_:64>>,'Elixir.Pop.Library.Re
source'}, 'group_bys'=>[], 'havings'=>[], 'id'=>'id', 'inserted_at'=>'utc_datetime', 'is_disabled'=>'boolean', 'is_pending'=>'boolean', 'joins'=>[], 'l10n'=>{'array','map'}, 'limit'=>'nil', 'lock'=>'nil', 'offset'=>'nil', 'order_bys'=>[], 'prefix'=>'nil', 'preloads'=>[], 'search'=>'m
ap', 'select'=>'nil', 'sources'=>'nil', 'tag_ids'=>{'array','integer'}, 'type'=>'string', 'updated_at'=>'utc_datetime', 'updates'=>[], 'wheres'=>[]}, 'preloads':=[], 'select':='nil', 'sources':='nil', 'updates':=[], 'wheres':=[#{'__struct__':='Elixir.Ecto.Query.BooleanExpr', 'expr':=
{'and',[],[{'==',[],[{{'.',[],['is_disabled' | 'is_pending' | {'&',[],[0,...]},...]},[],[]} | #{'__struct__':='Elixir.Ecto.Query.Tagged', 'tag':='nil', 'type':={0,'is_disabled' | 'is_pending'}, 'value':='false'},...]},...]}, 'file':=<<_:432>>, 'line':=10, 'op':='and', 'params':=[]},.
..]},tags@1::any()) does not have an opaque term of type 'Elixir.Ecto.Query':t() as 1st argument

This won’t happen with function2 though:
@spec function2(Ecto.Query.t) :: Ecto.Query.t
but will happen again with function3:
@spec function3(Ecto.Query.t) :: Ecto.Query.t

Note that functions alter query in a way, say, pipe it through where or whatever.

Any idea why the first and third @specs aren’t good?

From is a macro and creates a literal of the struct, therefore dialyzer sees the opacity violated. Limit is a macro as well and makes dialyzer think you were fiddling with the internals of the struct on your own, therefore it seems opacity violated.

1 Like

Why is @spec for function2 valid then, if it uses a macro as well in its function body, e.g where(query, ....).
Actually, this is the same for function1's return value as well, as this is valid: @spec function1(any()) :: Ecto.Query.t.

The specs for your functions seem to be valid, dialyzer complains about the calls.

x = from …
y = x
|> function1()
|> function2()
|> limit(10)


will probably be fine.

Unless you are running the query in function3/1, you can also swap the ordering:

x = from …
|> function1()
|> function2()
|> function3()
|> limit(10)

Unfortunately, this does not solve the issue, error messages remain the same.

I think I can see why it doesn’t for function1… But it remains for 3 as well when reordering calls?

Oh, sorry, yes, it does work for 3, because of reordering.

I have taken the freedom to actually post a bug report at ecto:


Nice, thanks.

It got fixed today, so once the next version gets released it should be fine.