import_types breaking change

[fuelen]

Environment

• Elixir version (elixir -v): 1.10
• Absinthe version (mix deps | grep absinthe): absinthe 1.5.1

Expected behavior

import_types(MyApp.Schema.Types.{Users, Posts})

imports types from MyApp.Schema.Types.Users and from MyApp.Schema.Types.Posts.
Absinthe 1.4.16 works fine with this kind of import

Actual behavior

== Compilation error in file lib/my_app/schema/schema.ex ==
** (ArgumentError) module Elixir.MyApp.Schema.Types.Users is not available

import_types(MyApp.Schema.Types.Users)
import_types(MyApp.Schema.Types.Posts)

^
works correctly

[marctrem]

I have experienced the same regression.

[binaryseed]

Does anyone have a minimal reproduction case?

[dylan-chong]

This seems to be working for me at the moment on 1.5.5

EDIT: I take that back

[binaryseed]

This was tracked down by @maartenvanvliet in #1022 !

I've published 1.6.0-rc.0 for folks to try out while we wrap up a few last items before a full release..

[hazardfn]

@binaryseed I am getting a similar variant to this issue in 1.6.3, my current setup works fine in 1.5.x:

Could not load module `Elixir.ApolloWeb.Schema.PostTypes`. It returned reason: `unavailable`.

I know for sure the module exists... I am not using the tuple layout as above just straight importing the types one after the other

[binaryseed]

Can you share more context? When does that happen? Can you generate a small reproduction case?

[bjunc]

I can replicate this in our app (not sure about a small / sharable repo), upgrading from 1.5.3 to 1.6.3

On a full build, I will get an "unavailable" module error like above; which has a union type. If I replace the union type with a simple object of the same name (just an id field), then it compiles. Seems union related.

Oddly, if I do the full build with the dummy object, then replace with the union for subsequent (app only) compilation, it'll work.

[sheharyarn]

Can confirm, we're facing a similar issue. Just tried upgrading absinthe from 1.5.5 to 1.6.x and now the schema fails to compile with the same message:

== Compilation error in file lib/myapp_graphql/schema.ex ==
** (Absinthe.Schema.Error) Compilation failed:
---------------------------------------
## Locations


Could not load module `Elixir.MyApp.GraphQL.Schema.AccountsSchema`. It returned reason: `unavailable`.
---------------------------------------
## Locations
/Users/Psy/code/my_app/lib/myapp_graphql/schema.ex:15

In Rootquerytype, :accounts_queries is not defined in your schema.

Types must exist if referenced.

---

After a bit of debugging, we found that the issue may be related to imports. For example, this does not work:

defmodule MyApp.GraphQL.Schema.AccountsSchema do
  use Absinthe.Notation
  import MyApp.GraphQL.Dataloader

  # ...

  object :user do
    # ...
    field :posts, list_of(:post), resolve: dataloader(Post)
  end

  # ...
end

But changing it to alias, does:

defmodule MyApp.GraphQL.Schema.AccountsSchema do
  use Absinthe.Notation
  alias MyApp.GraphQL.Dataloader

  # ...

  object :user do
    # ...
    field :posts, list_of(:post), resolve: Dataloader.dataloader(Post)
  end

  # ...
end

[josevalim]

The unavailable error means there is a deadlock when trying to resolve the modules. Probably due to cyclic dependencies between the several Absinthe schemas. More info here: https://hexdocs.pm/elixir/Code.html#ensure_compiled/1

I believe Absinthe has a module that resolves the types at runtime instead of compilation time. Is this correct? If so, consider using that instead, as that should fix compile-time deadlocks.

[benwilson512]

@josevalim yeah the default in the next release is to resolve everything at runtime and load it into :persistent_term. It makes it harder for us to have "compile time" errors on schemas, but given that the supervisor that loads the schema happens in the main application tree you at least get "at app start" errors.