Handle "unavailable" schema module status more correctly #266
Conversation
The Elixir documentation specifies for Code.ensure_compiled/1 that
{:error, :unavailable} is not necessarily an error condition, as the
deadlock could still be broken by the compiler. So we give the compiler
a little time to break the deadlock and retry a number of times before
we give up.
|
Anything you'd like me to do to help get this merged? |
|
@benwilson512 This fixes a pretty severe bug. It particularly affects users that need to pull in functions from other modules (e.g. values for enums). The race condition can completely break schema compilation, and the resulting error is very obscure. Given that the fix is so simple, can we get this merged? |
|
What version of Elixir are you on? |
|
Elixir 1.13.0 |
|
So, FYI, from the Elixir docs:
https://hexdocs.pm/elixir/Code.html#ensure_compiled/1 The For what it's worth, I've been using this patch in production for several months now, and it's completely resolved the schema build issues we were having, and doesn't seem to have introduced any new issues. |
|
@kdawgwilk Any chance we could get this merged? |
|
@kdawgwilk Is anything holding this back from getting merged? |
I've been dancing around these unpredictable "is not a valid
Absinthe.Schema" errors for months now, and finally took some time to figure out exactly what's going on. It turns out that when checking the validity of the schema withCode.ensure_compiled/1, it's possible that the module is not available yet, but may be later. We don't currently handle that condition, so if the compiler hits a particular race condition, the schema is simply rejected. This little tweak seems to fix my issues completely :)The Elixir documentation specifies for Code.ensure_compiled/1 that
{:error, :unavailable} is not necessarily an error condition, as the
deadlock could still be broken by the compiler. So we give the compiler
a little time to break the deadlock and retry a number of times before
we give up.