Sentry-javascript: In globalEventProcessors ausgelöste Fehler werden stillschweigend ignoriert

Erstellt am 22. Aug. 2019  ·  3Kommentare  ·  Quelle: getsentry/sentry-javascript

Paket + Version

@sentry/[email protected]

Beschreibung

Fehler, die in globalen Ereignisprozessoren geworfen werden, werden von der Sentry-Bibliothek aufgenommen, wodurch eine weitere Fehlererfassung eingeleitet wird, die wiederum denselben globalen Ereignisprozessor aufruft, der erneut einen Fehler auslöst. Dies wiederholt sich für eine unbekannte Anzahl von Malen (bis der Stapel vielleicht überläuft?). Das Problem besteht darin, dass es keine Spur des ursprünglichen Fehlers gibt und auch keine nachfolgenden Fehler, die vom fehlerhaften globalen Ereignisprozessor ausgelöst werden. Sentry ist offensichtlich nicht in der Lage, den Fehler in den Upstream zu senden, aber es wird auch nichts protokolliert.

Die Feststellung, dass ein fehlerhafter globaler Ereignisprozessor die Meldung unserer Fehler verhinderte, dauerte einige Zeit, daher wäre es großartig, wenn das SDK diese Fehler automatisch erkennen und protokollieren könnte. Bis dahin empfehle ich, den Verarbeitungscode in einen try/catch-Block zu packen und Fehler manuell zu protokollieren:

Sentry.addGlobalEventProcessor(event => {
  try {
    event.missingProperty.assignment = true
  } catch (err) {
    console.error('sentry global event processor threw error', err)
  }
  return event
})

Confirmed Bug

Alle 3 Kommentare

Ich konnte es nicht wie beschrieben wiederholen, kann jedoch bestätigen, dass der Fehler verschluckt wurde (sollte es nicht, da wir eine große catch Klausel in unserer Versprechenskette haben 🤔). Ich werde es bald untersuchen. Danke für den Bericht.

@kamilogorek bist du dazu gekommen, dich mit diesem Problem zu

@mogelbrod derzeit erhalten Sie ein Debug-Protokoll, wenn Sie debug: true festlegen und etwas fehlschlägt.
Gerade hier eine bessere Lösung implementiert https://github.com/getsentry/sentry-javascript/pull/2416

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen