Sentry-javascript: Le code source n'a pas été trouvé pour index.js

Pouvez-vous poster un lien direct vers l'événement ?

(vous avez également raté certains chemins dans la capture d'écran stacktrace que vous avez masquée plus tôt 😅)

Une raison particulière pour laquelle vous n'utilisez pas directement Sentry.captureException , mais souhaitez plutôt créer votre propre événement ?

Yepp, c'est l'événement : https://sentry.io/share/issue/e2c8d20b66d2406cb32c540d87654b4a/ (légèrement modifié pour ne pas publier notre dsn)

La raison pour laquelle j'utilise Sentry.captureEvent() est la suivante : je maintiens un plugin hapi qui capture les événements d'erreur générés par les gestionnaires de route hapi (enrichis avec les données de requête). Voir : hapi- sentry ./index.js#L41-L67

@guischdi la raison pour laquelle vous obtenez cette erreur est que les chemins de fichiers locaux ne sont pas accessibles aux serveurs distants.
Sentry essaie de récupérer et de résoudre /something/local/src/app.js et de lire le code source à partir de celui-ci pour fournir de meilleurs mappages d'erreurs (cela fonctionne de la même manière avec les fichiers sourcemap).

Pour télécharger vos fichiers, vous pouvez utiliser notre CLI https://docs.sentry.io/cli/ ou le plugin Webpack https://github.com/getsentry/sentry-webpack-plugin

Voici quelques anciens documents sur les cartes sources, mais le concept est le même pour le nouveau SDK https://docs.sentry.io/clients/node/sourcemaps/ (tout s'applique de la même manière à votre problème actuel).

Il existe également une intégration existante que vous pouvez utiliser pour réécrire les chemins dans chaque image https://github.com/getsentry/sentry-javascript/blob/master/packages/core/src/integrations/pluggable/rewriteframes.ts

Alors par exemple :

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

Changera /something/local/src/app.js en app:///app.js ( app:/// est notre préfixe interne), donc lorsque vous téléchargez app.js dans vos artefacts de version sentinelle, il sera lu correctement sans un besoin de récupérer des fichiers externes.

En gros, ce que vous devez faire, c'est :

• définir un release dans init appel
• téléchargez vos sources dans la même version dans Sentry
• assurez-vous que les images dans les erreurs que vous détectez correspondent à celles de vos fichiers de téléchargement

J'espère que cela clarifie certaines choses pour vous. N'hésitez pas à demander quoi que ce soit si vous avez besoin de plus d'aide.

Salut @kamilogorek
Merci pour votre réponse détaillée.

Ai-je bien compris : la manière courante d'afficher une trace de pile d'une application Node.js dans Sentry consiste à télécharger les fichiers de chaque version via l'intégration de RewriteFrames ou manuellement ? Si tel est le cas, comment se fait-il que la trace de la pile sur captureException /catch-all soit affichée et qu'aucune erreur "code source non trouvé" ne soit déclenchée.

J'ai testé le fonctionnement d'une erreur dans une node_modules . L'erreur est signalée correctement, y compris le code source, même à partir de la lib. Voir https://sentry.io/share/issue/2b95ecb13ce24227b2184b2561e4f6e3/

Alors pourquoi cela fonctionne-t-il avec captureException et échoue-t-il avec captureEvent ?

@guischdi pouvez-vous passer le lien complet vers les deux événements ? Pas partageables ? Je peux y accéder via les autorisations d'administrateur.

Aussi, je serai absent du bureau pour les 3 prochaines semaines, donc j'essaierai de revenir à celui-ci quand je reviendrai.

@kamilogorek

• c'est le lien captureEvent
• c'est le lien captureException

Merci d'avoir jeté un œil à ça !

@kamilogorek Voulez-vous dire que je dois également télécharger le dossier entier node_modules pour chaque version ? Pourquoi @sentry/node lors de l'exécution sur le serveur et que toutes ces sources sont disponibles ne peuvent tout simplement pas télécharger les fichiers nécessaires avec un rapport d'erreur ?

Je confirme qu'après avoir défini l'intégration des cadres et téléchargé l'intégralité de node_modules ce problème me résout. Mais le processus de téléchargement d'autant de fichiers node_modules est extrêmement lent.

Je pense que la solution à cela est soit :

1. autoriser par sentinelle à télécharger un .tar de la version entière
2. compilez le projet de nœud en un seul .js et .map et déployez et téléchargez uniquement ces deux fichiers.

De plus, j'avais un problème avec les cartes source qui référençaient le fichier .ts qui n'était pas dans le package node_modules npm - https://github.com/prisma/graphql-middleware/issues/159

@kamilogorek Des nouvelles sur ce problème ?

Je peux également confirmer que la réécriture des cadres était la solution pour nous.

Notre cas est un peu différent, nous essayions de faire fonctionner les sourcesmaps, mais le fichier minifié était toujours celui utilisé par Sentry. Pour la version correspondante, nous mettons en ligne des fichiers minifiés ainsi que les sourcesmaps associées. Il semble que Sentry ne trouve pas le sourcemap et utilise par défaut le fichier minifié (qui est cependant toujours hébergé sur le même chemin que les sourcemaps).

Nous venons d'ajouter new Integrations.RewriteFrames() à la clé d'intégration de l'initialisation de Sentry, et les sourcesmaps ont commencé à être récupérées pour chaque nouveau problème.

Il est bon de savoir que l'intégration de RewriteFrames et le téléchargement de node_modules semblent résoudre le problème. Mais d'abord (comme @mieszko4 déjà mentionné), télécharger autant de fichiers est assez ennuyeux. Et de plus ma conclusion initiale était,

que la trace de la pile sur captureException /catch-all est affichée et qu'aucune erreur "code source non trouvé" n'est déclenchée

La question suivante reste donc ouverte :

Alors pourquoi cela fonctionne-t-il avec captureException et échoue-t-il avec captureEvent ?

Ou plus précisément : On peut simplement capturer une erreur via captureException sans problème, mais pour capturer via captureEvent un téléchargement de tous les fichiers ( intégration RewriteFrames ou manuellement) est nécessaire pour empêcher l'erreur "le code source n'a pas été trouvé". Est-ce un bug ou intentionnel, @kamilogorek ?

@guischdi désolé pour une réponse si tardive. J'ai un peu perdu une piste. Pouvez-vous me rafraîchir la mémoire sur ce qui se passe ici et fournir quelques exemples d'événements ?

@kamilogorek
Oui, notre problème est :

• captureException fonctionne très bien, même si un node_module renvoie une erreur ; voir cette exception de test
• captureEvent donner des sentinelles : error encountered while processing this event: [...] Source code was not found ; voir cet événement test

@guischdi juste pour confirmer, il s'agit d'un fichier js de nœud brut, n'est-ce pas ? pas de webpack, pas de compilation, pas de sources map. Un seul fichier index.js avec 2 appels différents sur des lignes différentes ? Pouvez-vous fournir le contenu de ce fichier si possible ?

@kamilogorek
Oui, nodeJS brut. Jetez un oeil à la deuxième question que j'ai liée ci-dessus . Vous y voyez déjà les 13 lignes du index.js .

@guischdi, nous étudions pourquoi il se comporte ainsi (2 images consécutives avec la même URL déclenchent cela). En attendant, vous pouvez désactiver "Activer la récupération de source JavaScript" dans les paramètres de votre projet, par exemple. https://sentry.io/settings/kamil-ogorek/projects/testing-project/
C'est une application de nœud, donc cela ne sert à rien.

@kamilogorek Ok, j'ai désactivé le paramètre "Activer la récupération de source JavaScript" et déclenché une autre erreur. Mais toujours 1 error encountered while processing this event: [...] Source code was not found (voir ce numéro )

Bizarre, ça marche très bien pour moi. Quoi qu'il en soit, nous essaierons de déterminer pourquoi cela se produit, bien que je ne puisse pas promettre quand cela se produira, car ce n'est pas un problème majeur qui empêche quoi que ce soit de fonctionner. Vous tiendrons au courant!

@kamilogorek des nouvelles à ce sujet ?

Pour moi, la vue du problème signale le code source comme manquant de quelques fichiers, mais ils sont tous présents et visibles sous la trace de la pile.

J'utilise Sentry auto-hébergé et j'utilise @sentry/node 5.4.3

Voici mon code :

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

J'obtiens également cette erreur :

Et voici la pile :

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>

Je rencontre aussi ce problème Source code was not found

@LukeXF pouvez-vous fournir un lien vers un événement concerné ?

La raison pour laquelle vous pouvez voir le contexte source (c'est-à-dire le code au-dessus et au-dessous de la ligne en question) même si vous obtenez des erreurs "Impossible de trouver le code source" est que dans le SDK, avant d'envoyer l'événement, nous enregistrez ces informations dans le cadre du traitement du stacktrace . L'erreur vient du serveur _également_ essayant de remplir ces informations.

C'est un bogue de notre côté, cependant, car nous ne nous attendons pas à ce que vous téléchargiez node_modules avec chaque version (pour les applications de nœud ; pour les applications de navigateur, vous êtes probablement en train de regrouper/minifier de toute façon). Devrait être corrigé par https://github.com/getsentry/sentry/pull/17538, qui sera déployé dans quelques heures.

Une fois ce correctif terminé, est-ce que quelqu'un qui a commenté ici peut nous faire savoir si vous avez toujours des problèmes/questions, et quels sont-ils ? Heureux de le rouvrir si nécessaire.

Salut @lobsterkatie
testé à nouveau, avec l'extrait suivant (supprimé du README actuel sur npm):

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

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

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

Malheureusement, nous obtenons toujours l'erreur Source code was not found sur https://sentry.io/share/issue/0247fe07741c4e358089461f113cef42/
Le correctif que vous avez présenté hier est-il déjà déployé ?

Également testé avec la version actuelle v4.xx (v4.6.6) et la dernière version (v5.14.0) de @sentry/node.

@guischdi, vous n'avez téléchargé aucun artefact, ni inclus une version dans votre configuration.

Veuillez d'abord suivre la documentation : https://docs.sentry.io/platforms/node/sourcemaps/

@kamilogorek

dans le SDK, avant d'envoyer l'événement, nous enregistrons ces informations dans le cadre du traitement du stacktrace. L'erreur vient du serveur essayant également de remplir ces informations.
C'est un bug de notre côté, car nous ne nous attendons pas vraiment à ce que vous téléchargiez des node_modules à chaque version

Si j'ai bien compris @lobsterkatie à ce stade (cité ci-dessus), je ne devrais pas avoir besoin de télécharger le code. Dans le lien du problème, vous pouvez voir tout le contexte du code source nécessaire pour comprendre le problème (dans ce cas, tout le code source du script). Cela semble donc être enregistré correctement. Je ne pense pas avoir besoin de télécharger / servir des sourcesmaps (comme votre lien le propose), car il s'agit d'un programme Node.js simple et non minifié.
Je pense que le seul problème qui reste, c'est l'erreur qui s'affiche bien que le contexte soit correctement fourni. Le serveur semble ne pas reconnaître qu'il n'a pas besoin de téléchargements supplémentaires de ma part. (Est-ce que j'ai bien compris @lobsterkatie ?)

@guischdi Le fichier qu'il recherche provient de votre application, pas de node_modules, donc la modification que j'ai apportée (pour exclure avec plus de succès le code tiers) ne s'appliquerait pas ici.

La raison pour laquelle nous essayons de traiter les cartes de source pour les applications de nœud est que s'il est vrai que le code n'est très probablement pas minimisé, il pourrait assez facilement être transpilé (s'il était écrit en tapuscrit, par exemple), et nous aurions donc besoin de source maps pour afficher le code tel qu'il est écrit plutôt que la sortie de babel.

Ok, donc cela ressemble à un bug UX pour moi. À mon avis, cela devrait (au moins pour les projets Node.js) n'être qu'un avertissement et il ne doit pas dire Source code was not found mais quelque chose comme Source maps were not found . Cela aurait évité un problème avec un historique de plus d'un an ;)
Si vous le souhaitez, vous pouvez rouvrir ce problème en tant que rapport pour quiconque travaille sur la partie frontend/affichage, ou simplement le laisser fermé et lui signaler ce malentendu. Merci beaucoup d'avoir enfin clarifié cela !