Deferred execution doesn't work nested within EntityResolver types

[paulpdaniels]

It seems that when accessing a field on a type that is being resolved by an EntityResolver, if the field returns a DeferredValue the resolver will simply hang until a timeout.

A minimized example: https://scastie.scala-lang.org/l8h4f0XXR2aeAqV1boQm2A

You can see that by changing the email field resolver to be something other than a Fetcher the application will complete successfully, but if you leave as a fetcher, it will hang forever.

I'm not sure if this is an issue with the base extendSchema operation within sangria, or just how the composition is done in this library, but I raise it here because this seems like this is going to come up the most with federated graphs.

[oskargotte]

I've seen this as well and I think it's related to this issue with the core Sangria implementation: sangria-graphql/sangria#465

The workaround we use, is to always return a DeferredValue from the entity resolvers. As mentioned here sangria-graphql/sangria#462 (comment)

So in your example the resolver could look something like this

val entity = EntityResolver[Unit, JsValue, Profile, ProfileById](
  "UserProfile",
  (p, _) => DeferredValue(profileFetcher.deferOpt(p.id))
            //Some(Profile(p.id))  
)

with a profileFetcher added to the DeferredResolver, e.g. https://scastie.scala-lang.org/xEcBxVkFQGCVuhKKJE0utQ

The issue is also touched upon in here: #285 (comment)
where a potential way forward would be to enforce the resolver of EntityResolver to always return a DeferredValue instead of any LeafAction as of now. That way you wouldn't have run into this problem. But perhaps it is just hiding another issue?

[paulpdaniels]

Interesting apparently I even replied to that issue at the time. Anyway thanks for the workaround! I'll close this since the issue is already open.