Closed dmaze closed 4 years ago
Hi, thanks for the very detailed report! I honestly don't remember if this was intentional or not 🙈 I will look back at the recent changes and see where it popped up!
By the way, the work around is to access those arguments by key, instead, for example:
args[:in] # instead of args.in
It's probably worth it to make the migration. In GraphQL 1.10, those args
objects will be plain Ruby hashes, at least by default.
Sorry, I don't realistically have the bandwidth to look into this further. I hope you can make the kind of refactor I suggested above! It will also be future-compatible, so it will definitely pay off.
We have been generally writing GraphQL services by writing out the GraphQL schema IDL and then creating the graphql-ruby object model by calling
GraphQL::Schema.from_definition
on it. This requires passing in a hash of resolver functions, which get passed the current object, the field arguments, and the current context. This setup has broken for us, specifically in graphql-ruby 1.9.8.A typical resolver map might look like this:
Notice that in the resolver function, we are calling
args.in
to get a specific input argument, andargs.in.s
to get a specific field value from that. We'd tie this together with the schema with code like:Test code to call this:
https://gist.github.com/dmaze/c93ec7aa36ee0b17df2ded223e3b5ac8 contains a complete example built around these fragments.
When I run this against graphql-ruby 1.9.7 it works correctly and I get an output
When I run this against graphql-ruby 1.9.8 or later, I get a
NoMethodError
whereargs.in
is not defined.As the backtrace hints, I'm currently using jruby-9.2.8.0 for this test.