@RafeArnold can you please give more context? What do you mean with previously? What is exactly the problem or error you are experiencing? I believe this code has like this forever and we need to have a good reason to change it.

when executing a graphql query that contains multiple operations, the operation to execute must be specified via the operationName parameter. currently, if the provided operation name does not match any of the operations in the query, an error is thrown. however there's an exception to this behaviour when the provided operation name is empty. in that case, the first found operation is returned instead. i dont understand what the motivation for this exception to the rule is. why would an empty operation name imply "just give me the first operation you find in the query"? id expect it to still throw an error explaining that there are no operations with an empty name.

Why would an empty operation name imply "just give me the first operation you find in the query".

We kinda agree with this in general, but we are wondering what is your use case? Can you provide more context? This code has been like this for 8+ years.

I kinda agree that its weird that in the case of "" it gives back the first.

Its trying to handle this case

{
   this
   valid
   operation
   has
   no 
   name
}

BUT its also a low level utitlity class. I would love to see examples of how this gets invoked with "" as an input.

We could fix it but I want to see the knock on effects. What parts of other higher level code are calling this and can we get tests for that

maybe i was too hasty with my solution here (teaches me not to submit prs as im rushing to leave the office).

an alternative solution to an empty operation name retrieving the first operation arbitrarily when multiple operations are supplied is to treat the empty operation name in the exact same way as the null operation name. i.e. throw an exception explaining that an operation name must be supplied if multiple operations are present in the query. that way, the existing functionality remains that allows the library users to supply an empty operation name when there is only a single (named or unnamed) operation in the query, but the unfortunate side effect of the implementation that allows an empty operation name when there are multiple operations is removed. it seems very unlikely that any library users would be relying on this side effect, as it seems more likely to be a bug than a design decision.

the fix for this would be to simply add the same operationName.isEmpty() check to the condition of line 76.

would this proposed change be more acceptable?

i've pushed a new commit that implements my proposed change

reading the GraphQL over HTTP spec, i see that "Setting the value of the operationName parameter to the empty string is equivalent to omitting the operationName parameter.", so my second pass at the fix brings it in line with the spec.

in terms of knock on effects, the method this PR alters is called with an operationName argument supplied directly via the ExecutionInput object that the user supplies to the high level GraphQL.execute and equivalent methods. so, if the user creates an ExecutionInput with an operationName field of an empty string, it would pass straight down into NodeUtil.getOperation unaltered. i'm happy to add a higher level test that shows this behaviour if you think it's worth it, @bbakerman.