GraphQL ignored-error-types should not rely only on ErrorClassification.toString()

Inizia da SentryGraphqlInstrumentation e analizza come error.getErrorType().toString() viene confrontato con ignored-error-types. Leggi il comportamento di ErrorClassification.toSpecification(...) di graphql-java, quindi definisci l'approccio di matching in modo che ExtendedValidationError possa essere ignorato senza sostituire l'interpolatore dei messaggi né fare affidamento su toString().

Problem Statement

I am using the GraphQL integration with:

• io.sentry:sentry-spring-boot-4
• io.sentry:sentry-graphql-22
• Sentry Java SDK 8.42.0
• com.graphql-java:graphql-java-extended-validation:24.0

I want to ignore expected GraphQL validation errors produced by graphql-java-extended-validation.

The configuration looks like this:

sentry.graphql.ignored-error-types:
  - BAD_REQUEST
  - UNAUTHORIZED
  - FORBIDDEN
  - NOT_FOUND
  - ExtendedValidationError

This works well for enum-like ErrorClassification values, but it does not work reliably for errors from graphql-java-extended-validation.
From what I can see, SentryGraphqlInstrumentation currently resolves the error type with:

error.getErrorType().toString()

and then compares that string with ignoredErrorTypes.
The problem is that graphql-java-extended-validation uses a private ResourceBundleMessageInterpolator.ValidationErrorType class. It does not expose a stable enum-like value via toString(). The semantic classification is exposed through ErrorClassification.toSpecification(...), which returns a map like:

{
  "type": "ExtendedValidationError",
  "validatedPath": [...],
  "constraint": "@..."
}

Because of this, I currently have to work around the issue by replacing the extended-validation MessageInterpolator and returning a custom ErrorClassification whose toString() returns ExtendedValidationError only when called from Sentry:

override fun toString(): String {
    if (stackWalker.callerClass == SentryGraphqlInstrumentation::class.java) {
        return "ExtendedValidationError"
    }

    return super.toString()
}

That workaround is brittle and depends on Sentry internals.
This looks related to #2899, which added easier GraphQL error filtering. The current string-based filtering solves enum-like classifications, but it is hard to use with custom ErrorClassification implementations where toSpecification(...) carries the meaningful classification.

Solution Brainstorm

Could Sentry support a more robust way to classify ignored GraphQL errors?

A few possible approaches:

1. When error.getErrorType() is present, call errorType.toSpecification(error) and, if it returns a map containing a type field, allow ignored-error-types to match that value.

2. Add a callback/predicate for GraphQL errors. This would allow applications to inspect GraphQLError, ErrorClassification, extensions, path, etc.

3. Pass the GraphQLError and/or ErrorClassification through the Sentry Hint, as mentioned in #2899, so users can filter these events in beforeSend without replacing the whole GraphQL instrumentation.

My preference would be option 1 for configuration compatibility, possibly combined with option 3 for advanced filtering.

This would also make the Sentry GraphQL integration work out of the box with graphql-java-extended-validation, which is an official companion library from the graphql-java project. Since Sentry Java already integrates with graphql-java, it would be helpful if expected validation errors from this commonly used library could be ignored without replacing the message interpolator or depending on ErrorClassification.toString().