Graphiql schema does not reload when `import_types` uses an alias

[dagumak]

I couldn't find any documentation or reports, so I apologize if it's a known issue. I just spent an hour debugging this and found out that the schema does not reload if you use import_types with an alias.

For example, this works:

  import_types(HelloWeb.Schema.Types.TestType)

And this works when recompiling everything, but not on subsequent changes in file:

  alias HelloWeb.Schema.{Types, Queries, Mutations}
  import_types(Types.{
    TestType,
    HelloType
  })

[benwilson512]

You're saying the old schema information remains even after you reload the page?

[dagumak]

You're saying the old schema information remains even after you reload the page?

Yeah, that is correct. I clicked the "Reload Schema" button manually and I can see it hitting the server triggering a compile as well, but the Graphiql interface just shows the old schema. Moreover, when I make changes directly in the schema file, it reloads as expected.

[dagumak]

@benwilson512 were you able to confirm this? do you need more information from me?

[benwilson512]

I have not had time to dig into this, sorry. For now I would simply avoid using the problematic aliases.

[dagumak]

I have not had time to dig into this, sorry. For now I would simply avoid using the problematic aliases.

No rush on my side, but just wanted to see if it was reproducible by others. For now, I'm avoiding aliases and will refactor in the future.

[zvlasic]

Can confirm it happens to me also.

[zvlasic]

Let me add some info. If I use

import_types(Project.{
   Module1,
   Module2
}

and do some changes on type (let's say - renaming a field), these changes would not be seen in test env, so I had to to force recompile in test env every time I did some changes.

I just found this issue and changed schema to

import_types(Project.Module1)
import_types(Project.Module2)

and it solved the problem!

[kyleboe]

Confirmed here as well. I have to run a mix clean before starting up whenever one of the imported files changes.

[conradwt]

I haven't been able to reproduce this issue after upgrading to both Erlang 24.2 and Elixir 1.13. Furthermore, I recently refactored the GraphQL layer that did remove all the aliases from top-level schema.ex file. When changing the types of any of the import_types, I simply just refresh the browser and I'm all good.

[linomassarani]

Same thing here, the Absinthe.Schema.Notation.import_types/2 macro is working fine, I've tested it for a while, it does the job.

But there is still a problem if you use {}, when an imported type changes it won't take effect.

For example, if we have this on the Schema:

defmodule MyWeb.API.Users.Schema do
  @moduledoc false
  use Absinthe.Schema

  alias __MODULE__
  
  import_types(Schema.{User})  # Attention to the "{"User"}"
  [...]

And User module has something like this (working fine):

defmodule MyWeb.API.Users.Schema.User do
[...]

  object :profile do
    field(:cool_profile_field, :string, resolve: &Resolver.get_cool_profile_field/3)
  end
[...]

If we change that field to something like field(:new_cool_profile_field, :string, resolve: &Resolver.get_cool_profile_field/3), it wont work anymore until I recompile everything.

The result for the Absinthe.run/4 would be:

  {:ok,
   %{
     errors: [
       %{
         locations: [%{column: 11, line: 9}],
         message:
           "Cannot query field \"new_cool_profile_field_\" on type \"Profile\". Did you mean \"coolProfileField\"?"
       }
     ]
   }}

But if you change to the following (removing the {}) all the changes will take effect and you don't need to recompile:

defmodule MyWeb.API.Users.Schema do
  @moduledoc false
  use Absinthe.Schema

  alias __MODULE__
  
  import_types(Schema.User)
  [...]

The same problem occurs without the alias: import_types(MyWeb.API.Users.Schema.{User}) .

This is very odd.

Erlang/OTP 24 [erts-12.2.1]
Elixir 1.13.0
Absinthe 1.7.0

[jnicklas]

Can confirm as well. Took me a long while to figure out that this is related to the import_types Quox.{Foo,Bar} form. Importing individually fixes the problem.