Les erreurs front-end dans AppSignal

La vue Errors répertorie les erreurs que votre front end a rapportées, regroupées en issues. C’est le même modèle d’issues que celui de vos erreurs back-end : tout ce que vous faites déjà avec une exception venue de Ruby ou de Node.js fonctionne aussi ici.

​

Comment les erreurs sont regroupées

Les occurrences d’un même type d’erreur sur une même route forment une seule issue. Un bug qui se déclenche dix mille fois est une seule chose à trier, au lieu de dix mille notifications. La route est celle que le SDK a rapportée via setRouteTemplate(), ou le chemin de la page si rien n’a été déclaré. C’est pourquoi déclarer des templates compte : sans eux, /orders/1 et /orders/2 sont des routes différentes, et un bug se fragmente en une issue par commande.

​

Lire la liste des issues

Chaque issue de la liste porte :

• La classe d’erreur et le message, avec la route sur laquelle l’erreur s’est produite.
• La version dans laquelle elle a été introduite, souvent le moyen le plus rapide de repérer une régression : une nouvelle issue sur votre release la plus récente est une release à regarder de près.
• Une tendance sur la période sélectionnée, pour qu’un pic se lise différemment d’un filet continu.
• Le nombre total d’occurrences sur la période.
• La date de la dernière occurrence.
• La personne à qui elle est assignée.

Vous pouvez trier par occurrence la plus récente ou par volume, selon que vous triez ce qui vient de casser ou ce qui casse le plus souvent.

​

Filtrer par période et par version

• Période. Des préréglages d’une heure à 30 jours, ou une plage personnalisée.
• Version. Restreignez la liste aux erreurs rapportées par une seule release. Combiné à la colonne d’introduction, c’est ainsi que vous confirmez si un deploy est responsable.

​

Enquêter sur une issue

Ouvrir une issue affiche un sample de l’erreur : quand elle s’est produite, la page concernée et le deploy dans lequel elle est apparue en premier, ainsi que quatre éléments à partir desquels déboguer.

• Le message d’erreur, en entier. C’est là que se trouve le sens. TypeError ne dit presque rien à lui seul, tandis que Failed to fetch dynamically imported module vous apprend qu’un chunk chargé paresseusement n’est jamais arrivé.
• Les tags que vous avez définis avec setTags(), affichés à côté du user agent et de la révision, si vous avez défini appVersion. Quelques noms de tags font plus que filtrer. Taguez avec country_code ou browser et vous obtenez des distributions d’attributs, qui montrent quels pays ou quels navigateurs voient le plus d’erreurs. Les templates de liens transforment un tag en lien, si bien qu’un tag user_id peut ouvrir cet utilisateur dans votre propre back-office.
• La backtrace, que vous pouvez lire en entier ou restreinte à votre propre application. Les stacks front-end sont souvent presque entièrement composées de frames de framework. Un échec de removeChild venu de React arrive comme un mur de frames react-dom sans rien de chez vous en vue, et la vue application est ce qui permet d’y voir clair.
• La chronologie des breadcrumbs qui a mené à l’erreur, et c’est généralement la partie qui vous sauve.

Chaque breadcrumb porte son propre détail. Une entrée réseau montre la méthode, l’URL, le statut de la réponse et la durée de la requête. Une entrée de sélection montre quel élément l’utilisateur a sélectionné. Une entrée de long task nomme le script qui a bloqué le thread principal, et pendant combien de temps. Une piste qui va d’une sélection à l’erreur en passant par une requête GraphQL de près de trois secondes constitue souvent l’explication complète, sans rien reproduire. Les backtraces issues d’un bundle minifié sont résolues grâce aux sourcemaps, mises en correspondance sur la version de l’application. Sans version définie, les backtraces restent minifiées. Un sample peut être exporté en JSON ou en Markdown, ce qui est le moyen le plus rapide de l’attacher à un ticket ou de le transmettre à un assistant. Chaque issue possède aussi un journal, où vous et votre équipe consignez en Markdown ce que vous avez trouvé.

​

Tri et notifications

Les issues peuvent être assignées, dotées d’un état, mises en sourdine et configurées avec leurs propres réglages de notification, et le reste de l’outillage d’incidents d’AppSignal fonctionne également sur elles. Pour en savoir plus, consultez Errors. Comme les erreurs front-end vivent dans le namespace browser (voir les namespaces), ces réglages sont distincts de ceux de votre back end. Si vous migrez depuis @appsignal/javascript, notez que ses erreurs étaient rapportées dans frontend : les réglages de notification que vous y avez configurés ne sont donc pas repris. Pour en savoir plus, consultez le guide de migration.

​

Les erreurs que vous ne trouverez pas ici

Certaines erreurs n’atteignent jamais le SDK, notamment celles levées avant son initialisation, celles venues de scripts cross-origin servis sans en-têtes CORS, et celles à l’intérieur d’iframes. Chacune a une solution de contournement, répertoriée dans les erreurs qui ne sont pas rapportées. S’il manque une erreur que vous attendiez, parcourez le dépannage.