Sentry-javascript: Propriété de message d'erreur enregistrée en tant que [objet ErrorEvent]

Y a-t-il une définition de ErrorEvent quelque part dans la documentation Angular? Apparemment, ce n'est pas "hériter" de Error de la bonne manière.

Le problème pourrait être dans la méthode traceKitWindowOnError() TraceKit, cela ne semble pas prendre en compte le fait que l'argument message pourrait être un ErrorEvent (voir la documentation MDN )

@benvinegar Il y a quelques documents ici sur ErrorEvent : https://developer.mozilla.org/en-US/docs/Web/API/ErrorEvent

Cela affecte également ces utilisateurs:
https://forum.sentry.io/t/reporting-object-errorevent/1807

[email protected] (mais cela se produit depuis un certain temps également sur les anciennes versions)
Angulaire 4.x
Utilisation de la CLI

Idem ici avec Ionic 3 et [email protected]

<script>
  undefined.foo();
</script>

^ Ceci dans votre html est enregistré dans safari via sentry comme [object ErrorEvent] . Le message correct aurait été TypeError: undefined is not an object (evaluating 'undefined.foo') .

Nous avons un script externe qui injecte du code via une balise de script qui tente de créer une iframe, mais qui est bloqué par safari. Comme l'erreur provient de la balise de script injectée, sentry signale simplement [object ErrorEvent]

Une autre erreur de sentinelle signalée comme juste [object Event] provient du flowplayer. Le flowplayer fait

jQueryElement.trigger('error', [api, {code: 5}]);

Vous pouvez le reproduire en incorporant jQuery et faites simplement:

$('div:first').trigger('error')

Sentry voit quelque chose comme ça

Bien sûr, ce n'est pas très sérialisable, mais une erreur comme error on element from jQuery - context <div class="foo><div class="bar" ... serait beaucoup plus utile que [object Event]

Également affecté par cela.

@daangeerdink @jdelaune @rosslavery @tgensol quelqu'un pourrait-il fournir le plus petit code possible qui pourrait m'aider à reproduire cela?

@sod Je viens de vérifier, et Safari 10.1.2 fournit un message correct dans le scénario que vous avez mentionné ci-dessus.

Personnellement, je ne peux pas fournir de repro, car les erreurs sont si opaques que je ne peux pas discerner quelle partie de ma base de code génère l'erreur. Je n'ai pas de traces de pile avec lesquelles travailler, ni de message d'erreur pour savoir s'il s'agit de mon code, ou d'une bibliothèque tierce, etc.

J'espère que quelqu'un d'autre a un exemple simplifié à fournir, désolé je ne pourrais pas être plus utile.

Nous avons également ce problème. J'ai pu partager des données des 10 derniers jours (22k ​​événements de ce type, 13k utilisateurs). J'espère que cela vous aidera à le reproduire.

@kamilogorek Nous avons 2 millions d'erreurs de ce type. Je pensais que c'était notre problème, mais nous n'avons pas pu le suivre correctement.

J'ai trouvé le problème. ErrorEvent n'est pas traité comme une erreur par la fonction isError util, qui peut être trouvée ici . Pour plus de commodité, je vais également coller la définition de la fonction:

function isError(value) {
  switch ({}.toString.call(value)) {
    case '[object Error]':
      return true;
    case '[object Exception]':
      return true;
    case '[object DOMException]':
      return true;
    default:
      return value instanceof Error;
  }
}

J'ai fait un test rapide dans ma console pour voir si cette fonction renverrait true pour un ErrorEvent , et ce n'est pas le cas:

isError est utilisé dans la méthode captureException pour déterminer si le paramètre d'exception est une erreur ou simplement un message. captureException enverra des exceptions au tableau de bord en utilisant captureMessage s'il pense que l'exception n'est pas _en fait_ une erreur. Dans ce cas, Raven ne calculera pas de trace de pile ni ne "traitera" l'exception. Il l'envoie simplement tel quel.

Y a-t-il une raison pour laquelle nous ne devrions pas mettre isError jour ErrorEvent ?

Y a-t-il une raison pour laquelle nous ne devrions pas mettre à jour isError pour renvoyer true pour les objets ErrorEvent?

Oui. Parce que ce n'est pas réellement un descendant de Error (c'est un descendant de Event ). Il n'a pas stack propriété

Ce serait formidable de voir un exemple de la façon dont cette erreur est générée en direct, afin que nous puissions déterminer la meilleure façon de la traiter.

Le constructeur de ErrorEvent prend un Error , donc vous pouvez facilement les gérer comme ceci:

if (isErrorEvent(ex)) {
    ex = ex.error;
}

Vous pouvez voir la définition de construction ici . En particulier, regardez le hachage ErrorEventInit . C'est un paramètre facultatif, donc je suppose que la solution que j'ai publiée ci-dessus ne gère pas le cas où un ErrorEvent.error n'est pas défini.

Bien sûr, je pense que cela peut être résolu - je voulais simplement dire que ce n'est pas aussi simple que d'augmenter isError pour retourner true .

Je comprends. Je vais mettre en place un PR dans quelques minutes.

Fixé en 3.19.x

Merci @shcallaway! 👍

Il semble que nous ayons toujours ce problème sur 3.19.1 🤔

@PhilippSpo de quel navigateur provient cet événement? ErrorEvent n'est pas pris en charge dans certains anciens navigateurs mobiles et IE, nous avons donc dû revenir à une solution standard.

@kamilogorek Chrome 61.0.3163

Je le vois également sur Chrome 61. 😕 J'essaierai de l'examiner bientôt.

Merci @shcallaway

Cela se produit également sur Safari 11.0, Mac OS 10.13

Il semble que traceKitWindowOnError ne traite pas correctement les paramètres d'entrée lorsque le paramètre 'message' est un objet ErrorEvent:

et «ex» n'est pas défini. Ensuite, il appelle notifyHandlers avec un objet où le champ 'message' est un ErrorEvent, pas une chaîne:

qui, lorsqu'il est strigifié dans _makeRequest , produit un message sans signification.

Merci pour l'enquête @ michal-rumanek, j'essaierai bientôt de gérer ce problème (je n'ai pas de temps libre cette semaine).

@kamilogorek , des progrès? ;-)

Salut, je reçois beaucoup de ces erreurs [object Object] .

Angulaire 4
Chrome 62.0.3202
Raven-js 3.20.1

Corrigé dans https://github.com/getsentry/raven-js/pull/1162