@GraphQLIgnore on field with initial uppercase letter is ignored (e.g., ZAiConfigs)

[Ryokki]

The Problem

I'm using 0.12.4 of graphql-spqr.

The @GraphQLIgnore annotation does not correctly exclude a field from the generated GraphQL schema when the Java field name starts with an uppercase letter followed by another uppercase letter, e.g., zAiConfigs.

Steps to Reproduce

Consider the following Java data class:

import com.fasterxml.jackson.databind.JsonNode;
import io.leangen.graphql.annotations.GraphQLIgnore;
import lombok.Data;

@Data
public class SimplifiedServerSchema {
    private JsonNode apis;
    @GraphQLIgnore 
    private JsonNode zAiConfigs; // Field name starts with 'z', then 'A'
}

When the GraphQL schema is generated, the field annotated with @GraphQLIgnore is not excluded.

Actual Behavior

The generated GraphQL schema includes the field ZAiConfigs (or similar casing), indicating that @GraphQLIgnore was not applied:

type SimplifiedServerSchema {
  apis: Json
  ZAiConfigs: Json # <-- This field should be ignored!
}

Expected Behavior

The field annotated with @GraphQLIgnore should be excluded from the generated schema, regardless of its initial casing, as follows:

type SimplifiedServerSchema {
  apis: Json
}

Observation / Workaround

If the field name is changed to follow standard camelCase naming convention (e.g., starting with a lowercase letter, like zaiConfigs), the annotation works as expected.

Working Example:

import com.fasterxml.jackson.databind.JsonNode;
import io.leangen.graphql.annotations.GraphQLIgnore;
import lombok.Data;

@Data
public class SimplifiedServerSchema {
    private JsonNode apis;
    @GraphQLIgnore 
    private JsonNode zaiConfigs; // Changed from zAiConfigs to zaiConfigs
}

Generated Schema (Correct):

type SimplifiedServerSchema {
  apis: Json
}

[Ryokki]

I've completed a debugging session and have pinpointed the exact call chain causing this behavior.

The issue is not a failure of @GraphQLIgnore itself, but a failure in the property discovery logic to associate the getZAiConfigs() getter with the zAiConfigs field. This is caused by a well-known edge case in java.beans.Introspector.decapitalize.

Summary

The library fails to link the getter and the field, causing them to be processed as two separate entities:

1. The Field (zAiConfigs): Is found by buildFieldAccessors, its @GraphQLIgnore annotation is read, and it is correctly excluded.
2. The Method (getZAiConfigs()): Is treated as an "orphaned" operation by buildMethodInvokers. Since the method itself lacks @GraphQLIgnore, it is incorrectly included in the schema as ZAiConfigs.

Detailed Call Chain

The failure originates in io.leangen.graphql.metadata.strategy.query.PublicResolverBuilder.

1. PublicResolverBuilder.buildQueryResolvers

This method attempts to find all resolvers. The key problem starts with its call to findProperties(params), which relies on io.leangen.graphql.util.ClassUtils.getProperties.

2. ClassUtils.getProperties - The Link Failure

This utility method iterates all getters to find matching fields and create Property objects.

1. It finds the method getZAiConfigs().
2. It calls findFieldByGetter(getter) to find the corresponding field.
3. findFieldByGetter internally uses ClassUtils.getFieldNameFromGetter(getter).
4. getFieldNameFromGetter extracts the name "ZAiConfigs" and calls java.beans.Introspector.decapitalize("ZAiConfigs").

3. The Root Cause: Introspector.decapitalize

This is the core of the problem. The decapitalize logic states that if the first two characters are uppercase (like "ZA"), the string is returned unchanged.

• Introspector.decapitalize("ZAiConfigs") returns "ZAiConfigs".
• It does not return "zAiConfigs".

4. The Consequence

1. Back in findFieldByGetter, the library now searches SimplifiedServerSchema.class for a field literally named "ZAiConfigs".
2. This lookup fails, as the field is named zAiConfigs.
3. findFieldByGetter returns Optional.empty().
4. Therefore, ClassUtils.getProperties does not create a Property object linking getZAiConfigs() to zAiConfigs.

5. Back in PublicResolverBuilder.buildQueryResolvers - "Property Splitting"

The process now "splits" the property:

• buildPropertyAccessors(properties...): The properties set passed to it does not contain zAiConfigs. This step does nothing.
• buildMethodInvokers(...):
  • This method finds "orphaned" methods that are not part of the properties set.
  • It finds getZAiConfigs().
  • The library then inspects the getZAiConfigs() method for @GraphQLIgnore. It's not there.
  • This method is incorrectly added to the schema as a new query.
• buildFieldAccessors(...):
  • This method finds "orphaned" fields.
  • It finds the zAiConfigs field.
  • It inspects the field for @GraphQLIgnore. It is there.
  • This field is correctly ignored.

This explains the final behavior. The workaround (renaming to zaiConfigs) works because Introspector.decapitalize("ZaiConfigs") correctly returns "zaiConfigs", allowing the link to be established and the @GraphQLIgnore on the field to be respected for the entire property.

[Ryokki]

😊 Could any of the maintainers help me? It seems the property discovery logic could be made more robust against this specific edge case, perhaps by also checking for a field name that matches the non-decapitalized getter.

[Ryokki]

Instead of changing the core decapitalize logic (which might be a breaking change), a solution with minimal impact could be to introduce a new annotation, similar to Jackson's @JsonProperty.

Perhaps something like @GraphQLProperty(value = "...")?

If this annotation existed, I could resolve the issue like this:

import io.leangen.graphql.annotations.GraphQLIgnore;
import io.leangen.graphql.annotations.GraphQLProperty; // <-- Proposed new annotation

@Data
public class SimplifiedServerSchema {
    private JsonNode apis;

    private JsonNode zAiConfigs; 
    
    @GraphQLProperty("zAiConfigs")
    public JsonNode getZAiConfigs() {
        return zAiConfigs;
    }
}