ValidationException: This field is required. Cet événement remontait plus de trois cents fois par semaine dans le tableau de bord Sentry d’un site institutionnel utilisant Gravity Forms pour ses formulaires de contact multiples. Rien d’anormal pourtant : il s’agissait simplement de visiteurs qui oubliaient de remplir un champ obligatoire, un comportement parfaitement normal d’un point de vue applicatif.
Le problème n’était pas l’erreur elle-même, mais sa remontée systématique comme exception applicative dans l’outil de suivi. À ce volume, les vraies anomalies du site, comme un timeout de connexion à la base de données, se noyaient dans un bruit permanent que plus personne ne consultait sérieusement.
Diagnostic : comprendre pourquoi Sentry capture ces événements
Le SDK PHP de Sentry capture par défaut toute exception non interceptée qui traverse la pile d’exécution PHP. Or, certaines validations de Gravity Forms, notamment celles ajoutées par des extensions tierces de validation avancée, lèvent une exception PHP standard plutôt que de simplement peupler le tableau d’erreurs natif de Gravity Forms via le filtre gform_validation.
add_filter( 'gform_field_validation', function( $result, $value, $form, $field ) {
if ( empty( $value ) && $field->isRequired ) {
throw new ValidationException( 'This field is required.' );
}
return $result;
}, 10, 4 );
Ce code, écrit par une extension tierce mal intégrée à l’écosystème Gravity Forms, provoquait la remontée systématique de l’exception dans Sentry à chaque champ obligatoire laissé vide, ce qui explique le volume observé sur un formulaire de contact fréquenté.
Correctif : filtrer par contexte avant l’envoi à Sentry
La correction la plus robuste ne consiste pas à supprimer l’exception côté extension tierce, ce qui casserait potentiellement d’autres comportements attendus, mais à filtrer côté Sentry avant l’envoi, en utilisant le hook before_send du SDK PHP pour ignorer ce type précis d’événement.
\Sentry\init( array(
'dsn' => getenv( 'SENTRY_DSN' ),
'before_send' => function( \Sentry\Event $event ): ?\Sentry\Event {
$exception = $event->getExceptions()[0] ?? null;
if ( $exception && $exception->getType() === 'ValidationException' ) {
return null;
}
return $event;
},
) );
Ce filtrage se base sur le type d’exception plutôt que sur le message, ce qui évite de laisser passer une variante légèrement différente du même message d’erreur qui échapperait à un filtrage par correspondance de texte exacte.
Ne pas filtrer trop large
Un piège fréquent à cette étape consiste à filtrer toutes les exceptions de type ValidationException sans distinction, ce qui masquerait une vraie anomalie si, par exemple, cette exception était un jour levée dans un contexte différent du formulaire de contact. Le filtrage a donc été affiné pour ne s’appliquer qu’aux exceptions portant un contexte gravity_forms ajouté explicitement par le code de validation.
Prévention : un test qui garantit le filtrage dans la durée
Pour éviter qu’une future modification du SDK Sentry ou du code de validation ne réintroduise ce bruit, un test automatisé simule l’événement d’exception et vérifie que le callback before_send le neutralise correctement avant tout envoi réseau.
- Simuler un événement Sentry avec une exception de type
ValidationExceptionet le contexte attendu - Vérifier que le callback
before_sendretourne biennull - Vérifier, à l’inverse, qu’une exception de type
PDOExceptiontraverse le filtre sans être bloquée
Ce deuxième cas de test compte tout autant que le premier : un filtre trop permissif qui bloquerait aussi les vraies erreurs applicatives serait pire que l’absence de filtrage, puisqu’il masquerait silencieusement des pannes réelles.
Résultat mesuré après déploiement
Une semaine après la mise en production du correctif, le volume d’événements Sentry lié à ce formulaire est tombé de plus de trois cents à moins d’une dizaine par semaine, ces derniers correspondant à de véritables anomalies ponctuelles (extension tierce en conflit, champ mal configuré après une modification du formulaire).
Un outil de suivi d’erreurs qui remonte du bruit en continu finit par être ignoré même quand il signale une vraie panne : le filtrage des faux positifs est une question de fiabilité, pas de confort.
Pour aller plus loin
La configuration précise de Sentry en environnement de production, notamment le taux d’échantillonnage des traces de performance, dépasse le cadre de cet article et mériterait un traitement dédié. Ce qui compte ici reste la méthode : diagnostiquer la source du bruit avant de filtrer, et toujours vérifier par un test que le filtrage laisse passer les vraies anomalies.
