Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#6,020 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@IamPritamAcharya y travaille déjà.

Depuis le 10/9/2026.

  • #6092 par @IamPritamAcharya — ouverte

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
52/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
graphql, java, spring-boot
Domaine
api, backend

Piste de recherche

Commencez dans SentryGraphqlInstrumentation et examinez comment error.getErrorType().toString() est comparé à ignored-error-types. Lisez le comportement de ErrorClassification.toSpecification(...) de graphql-java, puis définissez l’approche de matching afin que ExtendedValidationError puisse être ignorée sans remplacer l’interpolateur de messages ni dépendre de toString().

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Feature Java Platform: Java
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().

Langage dominant
Kotlin
Étoiles
1.4k
Forks
479
Merge moyen
2 j 17 h
PR mergées (30 j)
68

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de getsentry/sentry-java

Toutes les issues de getsentry/sentry-java

Issues similaires

Plus d'issues Kotlin

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.