Sentry-javascript: Sentry.captureException n'envoie l'événement à Sentry qu'une seule fois (AWS Lambda)

Créé le 26 févr. 2019  ·  3Commentaires  ·  Source: getsentry/sentry-javascript

Forfait + Version

@sentry/node

Version:

4.6.3

La description

J'essaie d'intégrer le nouveau SDK Sentry dans notre architecture sans serveur, nous avons un try-catch général autour de chaque gestionnaire, qui appelle captureException. En bref, voici à quoi ressemble notre code (j'ai omis notre logique métier et de nombreuses méthodes utilitaires).

Sentry.init({
  dsn: process.env.sentryUrl,
  environment: process.env.NODE_ENV,
  // debugging issue where we only get an event once
  beforeSend: (event, _) => { console.log(event.exception); return event }
});

async function wrapper(...) {
   try {
     handler(...)
   } catch(error) {
      Sentry.configureScope(scope => {
        scope.setTag("test", "Hello, world")
      })

      const eventId = Sentry.captureException(error)
      // debugging, log event id to see if captureException works
      console.log(eventId)

      const flushResult = await Sentry.flush(1000)
      console.log(flushResult) // see if flush succeeded
   }
}

J'ai fait en sorte que le gestionnaire lance toujours une erreur. Lorsque je fais la première demande, tout se termine très bien dans Sentry. A la deuxième demande, rien ne se passe. Quand je regarde dans CloudWatch, c'est ce que je trouve. J'ai ajouté des commentaires pour plus de commodité.

Première demande :

/// the eventId from captureException
2019-02-26T13:47:22.584Z: 8cf83e38081a4672841a6f795ce8105a 
/// the middleware defined in Sentry.init
2019-02-26T13:47:23.153Z: { values: [ { stacktrace: [Object], type: 'Error', value: 'This is an error' } ] } 
/// result of Sentry.flush
2019-02-26T13:47:23.294Z: true 

Seconde demande:

/// the eventId from captureException
2019-02-26T13:47:24.761Z fbc2c8b2a4d5447380a0f92dd87896f6
/// result of Sentry.flush
2019-02-26T13:47:24.963Z: true 

Comme vous pouvez le voir, il n'atteint jamais le middleware beforeSend lors de la deuxième requête, donc je suppose qu'il n'est jamais envoyé à Sentry.

Je dois noter que lorsque je fais Sentry.getCurrentHub().getClient().captureException(error) , cela envoie l'exception à Sentry à chaque fois, mais la portée configurée dans Sentry.configureScope n'est jamais appliquée à l'événement.

J'ai essayé de reproduire cela localement, mais cela ne se produit que lorsqu'il est déployé sur AWS Lambda.

Commentaire le plus utile

Il est possible qu'il soit dédupliqué.
Vous pouvez utiliser debug: true dans votre appel init pour voir ce qui se passe.

S'il est effectivement dédupliqué, vous pouvez supprimer cette intégration en utilisant :

Sentry.init({
  integrations: integrations => {
    return integrations.filter(integration => integration.name !== 'Dedupe');
  }
});

https://docs.sentry.io/platforms/node/default-integrations/

Tous les 3 commentaires

Il est possible qu'il soit dédupliqué.
Vous pouvez utiliser debug: true dans votre appel init pour voir ce qui se passe.

S'il est effectivement dédupliqué, vous pouvez supprimer cette intégration en utilisant :

Sentry.init({
  integrations: integrations => {
    return integrations.filter(integration => integration.name !== 'Dedupe');
  }
});

https://docs.sentry.io/platforms/node/default-integrations/

Intéressant. J'ai trouvé cela à la recherche d'un problème similaire. La déduplication de suppression l'a corrigé pour moi.

Je ferme ça car ce n'est pas un bug.
De plus, la prochaine version majeure rend Dedupe facultatif, ce qui signifie qu'il n'y a pas de déduplication par défaut.

Cette page vous a été utile?
0 / 5 - 0 notes