[5.x]: GraphQL schema validation error with `hasProduct: {status}` argument on variants query

[mgambella]

What happened?

[5.x]: GraphQL schema validation error with hasProduct: {status} argument on variants query

What happened?

I'm experiencing a schema validation error when using the status field within the hasProduct argument on the variants GraphQL query. The query works in GraphiQL, but fails during code generation with GraphQL Code Generator.

Steps to reproduce

1. Create a GraphQL query that filters variants by parent product status:

query ProductVariantsSearch($searchTerm: String = null, $limit: Int = 9) {
  variants(
    search: $searchTerm
    hasProduct: {status: ["enabled"]}
    orderBy: "score DESC"
    limit: $limit
  ) {
    __typename
    id
    title
    status
    product {
      id
      title
      status
    }
  }
}

2. The query executes successfully in GraphiQL (albeit very slowly on first run)

3. Run GraphQL Code Generator to generate TypeScript types:

pnpm graphql-codegen --require dotenv/config --config codegen.ts

4. Code generation fails with the following error:

✖ GraphQL Document Validation failed with 1 errors;
    Error 0: Field "status" is not defined by type "ProductInput".
      at /path/to/ProductVariantsSearch.gql:4:19

Expected behavior

The GraphQL schema should properly define the status field on the ProductInput type (or the appropriate input type used by hasProduct), allowing both GraphiQL execution and schema validation tools to work consistently.

Since the query works in GraphiQL, the runtime supports this field, but the schema introspection doesn't reflect this capability.

Actual behavior

• The query works in GraphiQL at runtime
• GraphQL Code Generator fails validation because status is not defined in the schema for ProductInput
• Removing hasProduct: {status: ["enabled"]} allows code generation to succeed

This suggests a discrepancy between the actual GraphQL implementation and the published schema definition.

Additional context

• Using a headless Craft CMS installation with Nuxt.js frontend
• Using GraphQL Code Generator with the following plugins:
  • typescript
  • typescript-operations
  • typescript-graphql-request

The issue appears to be that the ProductInput type (or related input type) in the GraphQL schema is missing the status field definition, even though it's supported at runtime. This causes schema validation tools to fail while the actual query execution succeeds.

Workaround: Currently removing the status filter from the hasProduct argument, but this prevents filtering variants by their parent product's status, so we are filtering for products enabled on client side.

Craft CMS version

5.8.19

Craft Commerce version

5.4.9

PHP version

8.2.29

Operating system and version

Ubuntu 24

Database type and version

MySQL 8.0.43

Image driver and version

Imagick 3.8.0 (ImageMagick 6.9.12-98)

Installed plugins and versions

[linear]

COM-494

[mgambella]

Workaround Found:
I was able to get codegen to run successfully by enabling "Query for non-enabled elements" in the GraphQL schema settings. This allows the schema to include the status field in the introspection, which resolves the validation error.

Feature Request:
However, this workaround isn't ideal for production use. Could we have variants automatically filtered to exclude those whose parent products are disabled, without requiring "Query for non-enabled elements" to be enabled?

Proposed behavior:

• When querying variants, automatically exclude variants belonging to disabled parent products
• This would eliminate the need to explicitly filter with hasProduct: {status: ["enabled"]}
• Keeps "Query for non-enabled elements" unchecked for better security/performance

This would provide a cleaner API experience and avoid exposing disabled content in the schema unnecessarily.

[mgambella]

IMPORTANT NOTE: by adding hasProduct: {status: ["enabled"]} in the variants query, the query itself becomes too much slow which is completely unusable at this point. Can this be fixed also?

[nfourtythree]

Hi @mgambella

Thank you for your detailed message, it was really useful to get an understanding of what is going on.

It has certainly sparked some thoughts of ours internally.

For the moment I can see that with your currently implementation you at least have things working.

Although there is two points:

1. You mentioned that it is very slow, could you give us an idea of the volume of data (products and variants) that you are dealing with
2. We can see how turning the "Query for non-enabled elements" might feel like it is not needed

To cover the second point we are going to investigate adding a new property/method to variant queries that would allow you to specify a bool to decide whether to return variants based on their product's status (maybe something like hasEnabledProduct).

Thanks!