Sentry-javascript: No se encontró el código fuente para index.js

¿Puedes publicar un enlace directo al evento?

(también te perdiste algunas rutas en la captura de pantalla de stacktrace que enmascaraste antes 😅)

¿Alguna razón en particular por la que no usas Sentry.captureException directamente, sino que quieres crear tu propio evento?

Sí, este es el evento: https://sentry.io/share/issue/e2c8d20b66d2406cb32c540d87654b4a/ (ligeramente modificado para no publicar nuestro dsn)

La razón por la que uso Sentry.captureEvent() es la siguiente: mantengo un complemento hapi que captura los eventos de error generados por los controladores de rutas hapi (enriquecido con datos de solicitud). Consulte: hapi- sentry ./index.js#L41-L67

@guischdi, la razón por la que recibe este error es que las rutas de los archivos locales no son accesibles para los servidores remotos.
Sentry está tratando de obtener y resolver /something/local/src/app.js y leer el código fuente para proporcionar mejores asignaciones de errores (funciona de la misma manera con los archivos de mapa fuente).

Para cargar sus archivos, puede usar nuestra CLI https://docs.sentry.io/cli/ o el complemento Webpack https://github.com/getsentry/sentry-webpack-plugin

Aquí hay algunos documentos antiguos sobre mapas de origen, pero el concepto es el mismo para el nuevo SDK https://docs.sentry.io/clients/node/sourcemaps/ (todo se aplica de la misma manera a su problema actual).

También hay una integración existente que puede usar para reescribir rutas en cada cuadro https://github.com/getsentry/sentry-javascript/blob/master/packages/core/src/integrations/pluggable/rewriteframes.ts

Así por ejemplo:

Sentry.init({
  dsn: "https://[email protected]/297378",
  integrations: [new Sentry.Integrations.RewriteFrames()]
});

Cambiará /something/local/src/app.js a app:///app.js ( app:/// es nuestro prefijo interno), por lo que cuando cargue app.js a sus artefactos de lanzamiento centinela, se leerá correctamente sin una necesidad de buscar archivos externos.

Básicamente lo que tienes que hacer es:

• establecer una llamada release en init
• sube tus fuentes a la misma publicación en Sentry
• asegúrese de que los fotogramas en los errores que detecte correspondan a los de sus archivos subidos

Espero que te aclare algunas cosas. No dude en preguntar cualquier cosa si necesita más ayuda.

Hola @kamilogorek
Gracias por tu respuesta detallada.

¿Lo hice bien?: ¿La forma común de mostrar un seguimiento de pila de una aplicación Node.js en Sentry es cargar los archivos de cada versión a través de la integración de RewriteFrames o manualmente? Si es así, ¿cómo es que se muestra el seguimiento de la pila en captureException /catch-all y no se activa el error 'código fuente no encontrado'?

Probé cómo funciona lanzar un error en una biblioteca node_modules . El error se informa correctamente, incluido el código fuente, incluso desde lib. Ver https://sentry.io/share/issue/2b95ecb13ce24227b2184b2561e4f6e3/

Entonces, ¿por qué funciona esto con captureException y falla con captureEvent ?

@guischdi, ¿ puede pasar el enlace completo a ambos eventos? ¿No son compartibles? Puedo acceder a ellos a través de permisos de administrador.

Además, estaré fuera de la oficina durante las próximas 3 semanas, así que intentaré volver a esta cuando regrese.

@kamilogorek

• este es el enlace captureEvent
• este es el enlace captureException

¡Gracias por echar un vistazo a esto!

@kamilogorek ¿Quiere decir que también necesito cargar la carpeta node_modules para cada lanzamiento? ¿Por qué @sentry/node cuando se ejecuta en el servidor y tiene todas estas fuentes disponibles simplemente no puede cargar los archivos necesarios con el informe de error?

Confirmo que después de configurar la integración de marcos y básicamente cargar todo node_modules resuelve este problema. Pero el proceso de carga de tantos archivos node_modules es extremadamente lento.

Creo que la solución a esto es:

1. Permitir que Sentry cargue un .tar del lanzamiento completo
2. compile el proyecto de nodo en .js y .map únicos e implemente y cargue solo estos dos archivos.

Además, tenía problemas con los mapas de origen que hacían referencia al archivo original .ts que no estaba en el paquete node_modules npm - https://github.com/prisma/graphql-middleware/issues/159

@kamilogorek ¿ Alguna noticia sobre este tema?

También puedo confirmar que reescribir marcos fue la solución para nosotros.

Nuestro caso es un poco diferente, estábamos tratando de hacer que los mapas fuente funcionaran, pero el archivo minimizado siempre fue el que usó Sentry. Para el lanzamiento correspondiente, estamos cargando archivos minificados, así como mapas de origen asociados. Parece que Sentry no estaba encontrando el mapa de origen y estaba predeterminado en el archivo minimizado (que todavía está alojado en la misma ruta que los mapas de origen).

Acabamos de agregar new Integrations.RewriteFrames() a la clave de integraciones para el inicio de Sentry, y los mapas de origen comenzaron a seleccionarse para cada nuevo problema.

Es bueno saber que la integración de RewriteFrames y la carga de node_modules parecen resolver el problema. Pero primero (como ya mencionó @mieszko4 ), cargar tantos archivos es bastante molesto. Y además, mi hallazgo inicial fue,

que se muestra el seguimiento de la pila en captureException /catch-all y no se activa el error "código fuente no encontrado"

Por lo que queda abierta la siguiente pregunta:

Entonces, ¿por qué funciona esto con captureException y falla con captureEvent ?

O más precisamente: uno puede simplemente capturar un error a través de captureException sin problemas, pero para capturar a través de captureEvent se requiere una carga de todos los archivos ( RewriteFrames integración o manualmente) para evitar el error "no se encontró el código fuente". ¿Es esto un error o una intención, @kamilogorek?

@guischdi lo siento por una respuesta tan tardía. Perdí un poco la pista. ¿Puedes refrescarme la memoria sobre lo que está pasando aquí y proporcionar algunos ejemplos de eventos?

@kamilogorek
Sí, nuestro problema es:

• captureException funciona bien, incluso si un node_module arroja un error; ver esta excepción de prueba
• captureEvent dar vueltas al centinela: error encountered while processing this event: [...] Source code was not found ; ver este evento de prueba

@guischdi solo para confirmar, este es un archivo js de nodo sin procesar, ¿verdad? sin webpack, sin compilación, sin mapas fuente. ¿Solo un archivo index.js con 2 llamadas diferentes en líneas diferentes? ¿Puede proporcionar el contenido de este archivo si es posible?

@kamilogorek
Sí, nodoJS sin procesar. Eche un vistazo al segundo problema que vinculé arriba . Ya ve las 13 líneas de index.js allí.

@guischdi estamos investigando por qué se está comportando así (2 fotogramas consecutivos con la misma URL desencadenan esto). Mientras tanto, puede desactivar "Habilitar la obtención de fuente de JavaScript" en la configuración de su proyecto, por ejemplo. https://sentry.io/settings/kamil-ogorek/projects/testing-project/
Es una aplicación de nodo, por lo que no tiene sentido hacer eso.

@kamilogorek Ok, desactivé la configuración "Habilitar obtención de fuente de JavaScript" y provoqué otro error. Pero aún 1 error encountered while processing this event: [...] Source code was not found (ver este problema )

Extraño, eso funciona para mí muy bien. De todos modos, intentaremos investigar por qué sucede eso, aunque no puedo prometer cuándo sucederá, ya que no es un problema importante que impida que algo funcione. ¡Te mantendré informado!

@kamilogorek alguna noticia sobre esto?

Para mí, la vista de problemas informa que faltan algunos archivos en el código fuente, pero todos están presentes y se pueden ver en el seguimiento de la pila.

Estoy ejecutando Sentry con alojamiento propio y uso @sentry/node 5.4.3

Aquí está mi código:

// file: <path>/code/cli
const Sentry = require('@sentry/node');
Sentry.init({ dsn: process.env.SENTRY_DSN });
function test () {
  throw new Error('test');
}
test();

También estoy recibiendo este error:

Y aquí está la pila:

Error: test
  File "<path>/code/cli", line 10, col 9, in test
    throw new Error('test');
  File "<path>/code/cli", line 13, col 1, in Object.<anonymous>
    test();
  File "internal/modules/cjs/loader.js", line 1063, col 30, in Module._compile
  File "internal/modules/cjs/loader.js", line 1103, col 10, in Module._extensions..js
  File "internal/modules/cjs/loader.js", line 914, col 32, in Module.load
  File "internal/modules/cjs/loader.js", line 822, col 14, in Module._load
  File "internal/modules/cjs/loader.js", line 1143, col 12, in Module.runMain
  File "internal/main/run_main_module.js", line 16, col 11, in null.<anonymous>

También me encuentro con este problema Source code was not found

@LukeXF, ¿ puede proporcionar un enlace a un evento afectado?

La razón por la que puede ver el contexto de origen (es decir, el código por encima y por debajo de la línea en cuestión) aunque obtenga errores de "no se puede encontrar el código fuente" es que en el SDK, antes de que enviemos el evento, registre esta información como parte del procesamiento de stacktrace . El error proviene del servidor _también_ tratando de completar esa información.

Sin embargo, eso es un error de nuestra parte, porque en realidad no esperamos que cargue node_modules con cada lanzamiento (para aplicaciones de nodo; para aplicaciones de navegador, es probable que esté agrupando/minificando de todos modos). Debe ser reparado por https://github.com/getsentry/sentry/pull/17538, que se implementará en unas pocas horas.

Una vez que se solucione, ¿alguien que haya comentado aquí puede informarnos si todavía tiene problemas/preguntas y cuáles son? Feliz de volver a abrir esto si es necesario.

Hola @lobsterkatie
lo probé nuevamente, con el siguiente fragmento (eliminado del LÉAME actual en npm):

const Sentry = require('@sentry/node');

Sentry.init({ dsn: process.env.DSN });

(async () => {
  Sentry.captureException(new Error('Good bye'));
})();

Desafortunadamente, todavía obtenemos el error Source code was not found en https://sentry.io/share/issue/0247fe07741c4e358089461f113cef42/
¿La solución que introdujiste ayer ya está implementada?

También probado con la versión actual v4.xx (v4.6.6) y la última versión (v5.14.0) de @sentry/node.

@guischdi , no

Primero siga los documentos: https://docs.sentry.io/platforms/node/sourcemaps/

@kamilogorek

en el SDK, antes de enviar el evento, registramos esta información como parte del procesamiento de stacktrace. El error proviene del servidor que también intenta completar esa información.
Sin embargo, eso es un error de nuestra parte, porque en realidad no esperamos que cargue node_modules con cada lanzamiento.

Si entendí @lobsterkatie justo en ese punto (citado arriba), no debería necesitar cargar el código. En el enlace del problema, puede ver todo el contexto del código fuente necesario para comprender el problema (en este caso, todo el código fuente del script). Así que esto parece estar registrado correctamente. No creo que necesite cargar/servir mapas de origen (como sugiere su enlace), porque es un programa Node.js simple sin minificar.
Creo que el único problema que queda es el error que se muestra aunque el contexto se proporciona correctamente. El servidor parece no reconocer que no necesita cargas adicionales de mi parte. (¿Estoy entendiendo eso bien @lobsterkatie ?)

@guischdi El archivo que está buscando es de su aplicación, no de node_modules, por lo que el cambio que hice (para excluir con mayor éxito el código de terceros) no se aplicaría aquí.

La razón por la que tratamos de procesar mapas de origen para aplicaciones de nodo es que, si bien es cierto que es muy probable que el código no esté minimizado, podría transpilarse con bastante facilidad (si estuviera escrito en mecanografiado, por ejemplo), por lo que necesitaríamos source maps para mostrar el código tal como está escrito en lugar de la salida de babel.

Ok, esto me parece un error de UX. En mi opinión, debería (al menos para los proyectos de Node.js) ser solo una advertencia y no debe decir Source code was not found sino algo como Source maps were not found . Esto habría evitado un problema con un historial de más de un año;)
Si lo desea, puede reabrir este problema como un informe para quien trabaje en la parte de interfaz/pantalla, o simplemente dejarlo cerrado e informarles sobre este malentendido. ¡Muchas gracias por aclarar esto finalmente!