Omit optional parameter in the variables field of a request when the parameter value is null

[CalvinQuark]

There is a compatibility issue when using a ChilliCream StrawberryShake generated client to fetch data from an Azure Data API Builder CLI-generated GraphQL endpoint.

If a query is defined with an optional $filter parameter such as:

query Todos(
  $filter: TodoFilterInput
) {
  todos(
    filter: $filter
  ) {
    items {
      Id
      Title
      DueOn
    }
  }
}

When a null value is passed to filter parameter via a ChilliCream StrawberryShake-generated client query's .ExecuteAsync(filter: null) method, the request does not include the "filter": null node in the variables section:

{
    "id": "ec304833fcb193a31fdd994a6c503e21",
    "query": "query Todos($filter: TodoFilterInput) { todos(filter: $filter) { __typename items { __typename Id Title DueOn } } }",
    "operationName": "Todos",
    "variables": {}
}

Unfortunately, the Azure Data API Builder CLI's GraphQL endpoint responds to this request with:

{
  "errors": [
    {
      "message": "The variable with the name `filter` does not exist."
    }
  ]
}

unless the null-valued filter variable is specifically included in the request payload. I.e., this works:

{
    "id": "ec304833fcb193a31fdd994a6c503e21",
    "query": "query Todos($filter: TodoFilterInput) { todos(filter: $filter) { __typename items { __typename Id Title DueOn } } }",
    "operationName": "Todos",
    "variables": {
        "filter": null
    }
}

I haven't discovered a workaround for this issue either on the client side with StrawberryShake or on the server side with Azure Data API Builder. Is there a particular reason why it is necessary to include the unused null filter variable? If so, this seems unintuitive since the query parameter is declared as nullable $filter: TodoFilterInput. I.e., it's not suffixed with the required operator (!).

[CalvinQuark]

When I posed the following question to ChatGPT-4,

Suppose the invoker of this query (i.e., the Todos query above) seeks an unfiltered response and therefore doesn't include a null value for the filter parameter in the HTTP request. If the server responds with an error unless the request's payload includes the filter{ ... , "variables": { "filter": null } }, is the server compliant with the GraphQL spec? It seems like an optional parameter shouldn't have to be supplied.

the bot responded:

In GraphQL, if an argument is optional, the client should not be required to include it in the query. If an argument has a default value defined in the schema, or if it's nullable and there's no default value provided, the client does not need to provide a value for it.

Here’s a breakdown of how it should work according to the GraphQL specification:

Non-Required Arguments: If an argument is not required (non-null without a default value), then the client does not have to provide it. The server should handle the absence of this argument without any error, assuming it's correctly set up to do so.

Default Values: If a default value is provided in the GraphQL schema, then the server should use that value when the client does not provide the argument.

Null Values: If the client explicitly sets an argument to null, it means the client is explicitly passing null, which can be different from not providing the argument at all, depending on the schema and the server implementation.