Sentry-javascript: Propiedad del mensaje de error registrada como [objeto ErrorEvent]

¿Existe una definición de ErrorEvent en algún lugar de los documentos de Angular? Aparentemente, esto no es "heredar" Error de la manera correcta.

El problema podría estar en el método traceKitWindowOnError() TraceKit, no parece tener en cuenta que el argumento message podría ser un ErrorEvent (consulte los documentos de MDN )

@benvinegar Hay algunos documentos aquí en ErrorEvent : https://developer.mozilla.org/en-US/docs/Web/API/ErrorEvent

También afectados por esto, también lo son estos usuarios:
https://forum.sentry.io/t/reporting-object-errorevent/1807

[email protected] (pero también ha estado sucediendo durante un tiempo en versiones anteriores)
Angular 4.x
Usando CLI

Lo mismo aquí con Ionic 3 y [email protected]

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

^ Esto en su html está registrado en safari vía centinela como [object ErrorEvent] . El mensaje correcto habría sido TypeError: undefined is not an object (evaluating 'undefined.foo') .

Tenemos una secuencia de comandos externa que inyecta código a través de una etiqueta de secuencia de comandos que intenta crear un iframe, pero eso está bloqueado por Safari. Como el error se origina en la etiqueta de secuencia de comandos inyectada, Sentry solo informa [object ErrorEvent]

Otro error de Sentry informado como [object Event] es del flowplayer. El flowplayer hace

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

Puede reproducirlo incrustando jQuery y simplemente haga:

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

Sentry ve algo como esto

Seguro que eso no es muy serializable, pero un error como error on element from jQuery - context <div class="foo><div class="bar" ... sería mucho más útil que [object Event]

También afectado por esto.

@daangeerdink @jdelaune @rosslavery @tgensol ¿ alguien podría proporcionar un código lo más pequeño posible que pudiera ayudarme a reproducir esto?

@sod Acabo de verificar, y Safari 10.1.2 proporciona el mensaje correcto en el escenario que mencionaste anteriormente.

Personalmente, no puedo proporcionar una reproducción, porque los errores son tan opacos que no puedo discernir qué parte de mi código base genera el error. No tengo ningún seguimiento de pila con el que trabajar, ni un mensaje de error para averiguar si es mi código, o una biblioteca de terceros, etc.

Con suerte, alguien más tiene un ejemplo simplificado que puede proporcionar, lo siento, no podría ser de más ayuda.

También estamos teniendo este problema. Puedo compartir algunos datos de los últimos 10 días (22k ​​eventos de este tipo, 13k usuarios). Espero que te ayude a reproducirlo.

@kamilogorek Tenemos 2 millones de errores de este tipo. Pensé que era nuestro problema, pero no pudimos rastrearlo correctamente.

Encontré el problema. ErrorEvent no está siendo tratado como un error por la función isError util, que se puede encontrar aquí . Para mayor comodidad, también pegaré la definición de la función:

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;
  }
}

Hice una prueba rápida en mi consola para ver si esta función devolvería verdadero para un ErrorEvent , y no fue así:

isError se usa en el método captureException para determinar si el parámetro de excepción es un error o simplemente un mensaje. captureException enviará excepciones al tablero usando captureMessage si cree que la excepción no es _en realidad_ un error. En este caso, Raven no calculará un seguimiento de pila ni "procesará" la excepción. Simplemente lo envía como está.

¿Hay alguna razón por la que no deberíamos actualizar isError para devolver verdadero para los objetos ErrorEvent ?

¿Hay alguna razón por la que no deberíamos actualizar isError para que devuelva verdadero para los objetos ErrorEvent?

Si. Porque en realidad no es un descendiente de Error (es un descendiente de Event ). No tiene una propiedad stack , por ejemplo (AFAICT, jugando en la consola). Lo que significa que es posible que no se procese correctamente.

Sería genial ver un ejemplo de cómo se genera este error en vivo, para que podamos averiguar cuál es la mejor manera de procesarlo.

El constructor de ErrorEvent toma un Error , por lo que podría manejarlos fácilmente así:

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

Puedes ver la definición de construcción aquí . En particular, observe el hash ErrorEventInit . Es un parámetro opcional, así que supongo que la solución que publiqué arriba no maneja el caso donde un ErrorEvent.error no está definido.

Claro, creo que esto se puede resolver, solo quise decir que no es tan simple como simplemente aumentar isError para devolver true .

Entiendo. Pondré un PR en unos minutos.

Fijo en 3.19.x

¡Gracias @shcallaway! 👍

Parece que todavía tenemos este problema en 3.19.1 🤔

@PhilippSpo ¿De qué navegador proviene este evento? ErrorEvent no es compatible con algunos navegadores móviles antiguos e IE, por lo que tuvimos que recurrir a la solución normal.

@kamilogorek Chrome 61.0.3163

También lo veo en Chrome 61. 😕 Intentaré investigarlo pronto.

Gracias @shcallaway

También ocurre en Safari 11.0, Mac OS 10.13

Parece que traceKitWindowOnError no procesa correctamente los parámetros de entrada cuando el parámetro 'mensaje' es un objeto ErrorEvent:

y 'ex' no está definido. Luego, invoca notifyHandlers con un objeto donde el campo 'mensaje' es un ErrorEvent, no una cadena:

que, cuando se strigifica en _makeRequest , produce un mensaje sin sentido.

Gracias por la investigación @ michal-rumanek, intentaré resolver este problema pronto (no tengo tiempo libre esta semana).

@kamilogorek , ¿algún avance? ;-)

Hola, recibo muchos de estos errores [object Object] .

Angular 4
Cromo 62.0.3202
Cuervo-js 3.20.1

Corregido en https://github.com/getsentry/raven-js/pull/1162