Schema is not configured for mutations

[stevecrozz]

I am attempting to track down an issue with a production graphql-ruby app:

• I have a graphql app with two schemas. Both are configured with mutations.
• One particular mutation, very rarely gets this error and we have a front end error catcher that notifies us Schema is not configured for mutations: {"response":{"errors":[{"message":"Schema is not configured for mutations","locations":[{"line":1,"column":1}],"path":["mutation myMutation...
• We have over 60 mutations and only one mutation query ever seems to trigger this error
• Nothing looks interesting or different about this particular mutation query. In fact, I am able to run this query without failure any number of times, exactly the same way (same query, same parameters)

I did read through #2359 but this issue is so old, I'm not sure if any of it is still relevant. What can I do to get to the bottom of this?

[rmosolgo]

Hey, sorry to hear about the trouble. That's really weird... I honestly don't have any guess at all what could be causing it, but I can offer a few debugging questions that might yield a useful clue:

• Does this happen in development, test, and production, or just one? (If it only happens in development, then it might be related to Rails' lazy autoloading of code files). If it's development-only, are you running a multithreaded Puma development server? Does it happen often enough that you could switch it to single-threaded for a while and see if that eliminates the problem? That'd be a very big clue...
• Does your schema have use GraphQL::Schema::Visibility? It's a new-ish implementation for def self.visible? that might have bugs -- and it also does a kind of lazy loading of GraphQL types.
  -Can you share any source code related to the one mutation that triggers this sometimes? Given that it's the only one, it seems likely to me that some particular detail about this mutation is causally involved. Anything you could share would be helpful: file name, mutation class name, GraphQL definition code for the mutation, def resolve implementation, field ... configuration where it's attached to the main mutation type.
• For the mutation where this occurs, does it happen on both schemas, or just one?
• Can you share your GraphQL version and Ruby on Rails version? That would help with debugging because I could be sure I'm digging in to the correct source code if I have any clues to follow.

[stevecrozz]

Very much appreciate the reply. Here's what I can answer

• I have only seen this happen in production, fwiw we are running single threaded puma in production
• we are not using GraphQL::Schema::Visibility
• This mutation is only present in one schema, so it only happens on that one
• Ruby version is cRuby 3.2.7
• GraphQL gem version is 2.4.13

This mutation isn't used as commonly as many others, but it has been executed 2500 times in the past 30 days in our production environment.

Occurrences of the error are lumpy and don't seem to correlate with usage patterns so I believe the explanation has to be something other than pure random chance. It has been 2 weeks since the last time we saw one of these:

[rmosolgo]

Thanks for sharing those details. This is definitely unique...

only in production

Woah, so it's definitely not Rails autoloading. When this happens, is it isolated to one host machine, or is it spread out among many hosts? Is it isolated to one process? Do the error spikes correlate with deploys at all? I'm really wondering if the problem is that a single host is somehow misconfigured, or booted up wrong, and then the place to look is application initialization, to see what could go wrong and cause this to 💥 .

Alternatively, could there be some issue in the normal, "stable" running state of the application that causes this to appear? Schema.mutation does have some interesting conditional logic, but by the time the application is running, only the else block should actually run: https://github.com/rmosolgo/graphql-ruby/blob/master/lib/graphql/schema.rb#L479-L508

And besides, Schema.query works the same way... but that one never causes this error, right? Do you ever see "Schema is not configured for queries"?

I took a quick look at the changelog and nothing jumped out before or after 2.4.13 that might be related 😖