La version 11.9.0 de Sentry-JavaScript arrive avec des changements notables ciblant les écosystèmes Deno et Next.js, notamment sur la manière dont les systèmes de traçage enregistrent les événements. Selon l’annonce de github.com, plusieurs noms d’origines de span ont été modifiés pour s’aligner sur d’autres versions v11. Les anciennes origines, comme auto.graphql.diagnostic_channel, sont remplacées par des noms plus précis, par exemple auto.graphql.graphql. Si vous utilisez des règles d’ignorance ou des alertes basées sur ces anciennes origines, il faudra les mettre à jour.

Pour les utilisateurs de Deno, l’intégration denoServeIntegration gagne en fonctionnalités. Elle accepte désormais des options comme ignoreRequestBody ou ignoreIncomingRequests, offrant un contrôle plus fin sur les requêtes entrantes. De plus, cette intégration enregistre une session de requête pour chaque appel reçu par Deno.serve, ce qui permet de calculer des métriques de santé applicative si une version de la release est définie.

Raffinements pour l’écosystème Next.js

Les développeurs travaillant avec Next.js bénéficient également de plusieurs ajustements. Un nouveau gestionnaire de route de tunnel permet d’envoyer uniquement la charge utile de l’événement à Sentry, sans inclure les en-têtes de requête. Par ailleurs, pour les pages prérendues, Sentry s’assure de ne jamais émettre de métadonnées de traçage. Ainsi, une page mise en cache ne peut plus lier un visiteur à une requête qui ne lui appartient pas.

L’intégration Nitro voit aussi son modèle de données simplifié : une requête Nitro ne crée plus de span imbriqués pour les routes HTTP. Les middleware sont désormais des enfants directs du span http.server.

La robustesse du symbolication face aux erreurs de configuration

Si ces mises à jour sont orientées intégration, il est utile de se rappeler que le processus de déchiffrement des erreurs, la symbolication, repose sur des systèmes complexes. Sentry utilise son service Symbolicator, une solution open-source écrite en Rust, pour traiter les stacktraces natifs et les minidumps. Ce service est crucial pour transformer le code minifié en une trace lisible, pointant vers le fichier et la ligne originaux.

Ce système a récemment été mis à l’épreuve par un problème critique. Selon le blog de Sentry, des noms de release mal formés, comme VERCEL_GIT_COMMIT_SHA sans expansion correcte, ont engendré une surcharge colossale sur la base de données Postgres 14. Ces noms provoquaient des recherches non bornées, faisant grimper l’utilisation du CPU à 76 % sur les hôtes principaux. La solution implémentée, datant d’octobre, a consisté à imposer un budget de lignes pour les recherches URL, plafonnant le travail d’une seule requête à un million de lignes d’index. Cette mesure a permis de faire chuter l’usage du CPU à 19 %.

Ce cas montre que même les outils sophistiqués sont vulnérables aux erreurs de configuration en amont, comme l’utilisation d’une variable d’environnement non résolue dans un système CI. Le dépôt getsentry/symbolicator témoigne de l’architecture sous-jacente qui supporte ces capacités de débogage pointues. Il faudra surveiller comment ces améliorations d’intégration se combinent avec la robustesse des services sous-jacents.

Sources

• Release 11.9.0 · getsentry/sentry-javascript, github.com
• GitHub – getsentry/symbolicator: Native Symbolication as a Service, github.com
• How a broken release name overloaded our symbolication database, Sentry, 9 novembre 2026