Describe the bug
DataFetchingEnvironment.getVariables() says: @return the variables that have been passed to the query that is being executed. So I expected to get exactly the same map that I provided in my ExecutionInput. This is not true: I get an empty map if I pass variables that I haven't defined in my query, because ExecutionHelper calls ValuesResolver.coerceVariableValues().
To Reproduce
- Execute a simple query and pass in the execution input some variables that are not defined as query variables
- In your datafetcher, call DataFetchingEnvironment.getVariables()
- You get an empty map instead of a map containing the input variables
The workaround is easy, I put my input variables in my context and uses that instead.
I understand that per the GraphQL spec variables that I want to use in my query have to be defined. But why couldn't I pass variables at runtime that are used in my code for fetchers but do not appear in the query text? So should we really have a way to have the original map, and use getArguments for variables properly defined and types? If we don't want to change the behavior, can we change the Javadoc on the method (principle of least surprise...)?
Describe the bug
DataFetchingEnvironment.getVariables() says: @return the variables that have been passed to the query that is being executed. So I expected to get exactly the same map that I provided in my ExecutionInput. This is not true: I get an empty map if I pass variables that I haven't defined in my query, because ExecutionHelper calls ValuesResolver.coerceVariableValues().
To Reproduce
The workaround is easy, I put my input variables in my context and uses that instead.
I understand that per the GraphQL spec variables that I want to use in my query have to be defined. But why couldn't I pass variables at runtime that are used in my code for fetchers but do not appear in the query text? So should we really have a way to have the original map, and use getArguments for variables properly defined and types? If we don't want to change the behavior, can we change the Javadoc on the method (principle of least surprise...)?