Evan Huus

The comment in `build_from_definition.rb` is ``` # Make a different type resolver because we need to coerce directive arguments # _while_ building the schema. # It will dig for a...

🤔 I think that just moves the problem; I could write an equally short test which passes on main but fails with that hack in place (make a schema with...

That's a great summary, thanks Robert. We're chatting internally but we're coming around to the idea that the logging we want should ultimately be decoupled from `visible?` - that's going...

Allow resolve methods for interfaces to call e.g. `hint_concrete_type_is(Foo)` and then just use that instead of running through the interface type resolution again?

To determine which concrete type to use, the gem calls either `resolve_type(obj, ctx)` on the interface (in which case `self` is `Node` and `obj` is the instance of `Foo`), or...

We're not using the `.define` API, we're fully class-based at this point. The problem is *in* the call to `resolve_type`, not after it.

@rmosolgo is this something that the new interpreter might have unintentionally fixed? We just noticed by accident that it seems to work now without the workaround we put in place?...

Either https://github.com/rmosolgo/graphql-ruby/issues/1802#issuecomment-415491269, or find a way to make the arguments of the field available to the `resolve_type` method on interfaces or unions.

> you can modify the incoming argument values in `def resolve` That works, but gets pretty awkward for deeply nested / complex / reused inputs. It would be nice if...

Looks like I ran into part of this same issue way back in 2016 😂 😬 https://github.com/rmosolgo/graphql-ruby/issues/139