QUESTION: What might cause The argument `where` does not exist. (unit testing)

Is there an existing issue for this?

I have searched the existing issues

Describe the bug

Firstly I’d like to say I searched, searched the code for this error message, and asked in slack chat first and got nowhere with that. This may not be a bug but a configuration issue.

I’ve got graphql integration that works, and altair / banana cake pop both can query with filtering criteria provided by a where keyword in the query parameters. While unit testing I get an error The argument where does not exist

Steps to reproduce

Setup request executor like so

var executor = await services
                .AddGraphQL()
                .AddQueryType<RootQuery>()
                .AddMutationType<RootMutation>()
                .AddSorting()
                .AddFiltering()
                .AddProjections()
                .BuildRequestExecutorAsync()

Execute query like so:

var variables = new Dictionary<string, object>()
            {
                {
                    "id", new IntValueNode(34l)
                }
            };

            var query = QueryRequestBuilder.New()
                .SetQuery(@"query get($id: Long)
                {
                    getQuotes(where: {id: $id})
                    {
                        id
                    }
                }")
                .SetVariableValues(variables)
                .Create();

            var result = await _executor.ExecuteAsync(query);

Observe results of the query resulting in two errors and no data.

Message: The argument `where` does not exist.
SyntaxNode: {where: { id: $id }}

and

Message: "The following variables were not used: id."
SyntaxNode: {query get($id: Long) {
  getQuotes(where: { id: $id }) {
    id
  }
}}

Relevant log output

No response

Additional Context?

I’m upgrading hotchocolate 10.2.0 to 12.7.0, and these tests worked prior to my changes / library upgrade.

It feels like this is PROBABLY something where the necessary stuff for filtering isn’t being generated for the purposes of unit testing, but the configuration of the irequestbuilder is the same as I configure GraphQL in the actual server, and the Query is identical.

Again, I don’t think this is ACTUALLY a bug, and probably something I’m just running into because of configuration, but as I said, even with the source of hotchocolate, I haven’t been able to see what code even generates that error message.

Product

Hot Chocolate

Version

12.7.0

Issue Analytics

State:
Created a year ago
Comments:6 (3 by maintainers)

Top GitHub Comments

1reaction

ronnyekcommented, Apr 19, 2022

I didnt have a lot of involvement in the initial implementation of these graphql stuff initially, but it looks like getQuotes just calls directly to a service. There is a QuoteResolver that appears to look up linked types.

The query definition of this method looks liek

[GraphQLName("getQuotes")]
[GraphQLDescription("Retrieves quotes.")]
public async Task<List<Quote>> GetQuotes(IResolverContext resolverContext)
{
     return await _quoteService.GetQuotesAsync(resolverContext.GetQueryFields());
}

and the querytype

protected override void Configure(IObjectTypeDescriptor<EstimatingQuery> descriptor)
        {
            // Quote
            descriptor.Field(i => i.GetQuotes(default))
                .Type<ListType<QuoteType>>()
                .UseFiltering()
                .UseSorting();
}

As a side mention, Ideally this stuff will migrated to efcore integration in which a lot of this stuff wouldn’t be one off… I’m just trying to get the library upgraded and functioning as it was before… then I can work with the team to migrate things to use the efcore integration (which in my experience has been much simpler and complete)

0reactions

ronnyekcommented, Apr 19, 2022

You know I think this could be the problem. I’ve got RootQuery->Estimating->GetQuotes [GraphQLType(typeof(EstimatingQueryType))] exists in the root query when describing the estimating sub query, so if I was using EstimatingQuery / EstimatingMutation in the query executor, I could see how it may not have context to register anything from EstimatingQueryType

I think I’m happy with the reason why this was not working prior. I’ll go ahead and close this, and I appreciate all the feedback