@sentry/[email protected]
Les erreurs lancées dans les processeurs d'événements globaux sont récupérées par la bibliothèque Sentry, initiant une autre capture d'erreur qui appelle à son tour le même processeur d'événements global qui lancera une fois de plus une erreur. Cela se répète un nombre inconnu de fois (jusqu'à ce que la pile déborde peut-être ?). Le problème est qu'il n'y a aucune trace de l'erreur d'origine, ni d'erreurs ultérieures générées par le processeur d'événements global défectueux. Sentry est évidemment incapable d'envoyer l'erreur en amont, mais rien n'est enregistré non plus.
Découvrir qu'un processeur d'événements global défectueux empêchait la signalisation de l'une de nos erreurs a pris un certain temps, il serait donc formidable que le SDK puisse détecter et enregistrer ces erreurs automatiquement. Jusque-là, je recommande d'envelopper le code de traitement dans un bloc try/catch et de consigner manuellement les erreurs :
Sentry.addGlobalEventProcessor(event => {
try {
event.missingProperty.assignment = true
} catch (err) {
console.error('sentry global event processor threw error', err)
}
return event
})
Je n'ai pas pu le boucler comme décrit, mais je peux confirmer que l'erreur est avalée (cela ne devrait pas, car nous avons une grande clause catch
dans notre chaîne de promesse 🤔). Je vais enquêter bientôt. Merci pour le rapport.
@kamilogorek avez-vous eu le temps de vous pencher sur ce problème ?
@mogelbrod actuellement, vous obtiendrez un journal de débogage lorsque vous définissez debug: true
et que quelque chose échoue.
Je viens de mettre en œuvre une meilleure solution ici https://github.com/getsentry/sentry-javascript/pull/2416