How to capture single error instance multiple times?

[itsramiel]

OS:

• Windows
• MacOS
• Linux

Platform:

• iOS
• Android

SDK:

• @sentry/react-native (>= 1.0.0)
• react-native-sentry (<= 0.43.2)

SDK version: 5.31.1

react-native version: 0.75.2

Are you using Expo?

• Yes
• No

Are you using sentry.io or on-premise?

• sentry.io (SaaS)
• on-premise

If you are using sentry.io, please post a link to your issue so we can take a look:

Link to issue

Configuration:

(@sentry/react-native)

Sentry.init({
  dsn: <dsn>,
});

---

I have the following issue:

When I capture the same error two times, the second capture is not being reported on the website.
The reproducible here is redundant and is not very useful, but in an app I am working on it is more complicated. This example is just for the sake of reporting the issue

Steps to reproduce:

          const error = new Error('test');
          Sentry.captureException(error, scope => {
            scope.setTransactionName('transaction 1');
            return scope;
          });
          Sentry.captureException(error, scope => {
            scope.setTransactionName('transaction 2');
            return scope;
          });

Actual result:

Only the first capture was reported:

Expected result:
I expect to see both on the website

[krystofwoldrich]

Hi @itsramiel,
thank you for the message,

the second captureException is dropped because the SDK recognize that the instance of the supplied error was already captured by Sentry.

If you add debug:true to your options you will see

 LOG  Sentry Logger [log]: Not capturing exception because it's already been captured.

The following code will report two exceptions:

Sentry.captureException(new Error('test'), scope => {
  scope.setTransactionName('transaction 1');
  return scope;
});
Sentry.captureException(new Error('test'), scope => {
  scope.setTransactionName('transaction 2');
  return scope;
});

Details of the implementation are available here.

[itsramiel]

But since they were captured under two different scopes/transaction, then does it make sense for it to still be dropped.
Also do you think there could be an optioned added for this to be disabled?

[krystofwoldrich]

@itsramiel I understand the sample code was simplified to showcase the behaviour, but do you have an example form your application were capturing the error multiple time would help you debug it?

We capture the error the error once the first time, this should give you the context of error origin.

---

You can overwrite the __sentry_captured__ to false property on the error object to force the capture.

[itsramiel]

@itsramiel I understand the sample code was simplified to showcase the behaviour, but do you have an example form your application were capturing the error multiple time would help you debug it?

Sure, I use urql as my graphql client. When you create a client with urql and setup auth, you also pass a didAuthError which is a function that takes in an error and let urql know whether it was an auth error or not to refresh the access token.

The issue is that when you make a graphql client call and an error is thrown by the query/mutation then the error is thrown at call site and also passed to the didAuthError. I capture errors in the didAuthError always and the for the query/mutation call site not always, it depends.

The problem is that if I wanted to capture the error also at call site, then it will not be picked up because it was already captured in didAuthError, but I want to easily find errors at that specific call site using the transaction scope I set on it and not have to look for all error in didAuthError.

One argument would be to not capture errors in didAuthError and only at call sites which is valid I think but still I would have expected sentry to act as expected.

You can overwrite the __sentry_captured__ to false property on the error object to force the capture.

Sounds like an implementation detail that could change and this would no longer work

[krystofwoldrich]

Hi @itsramiel,
thank you for the details,

let me create small simplified snippet, to confirm I understand the situation correctly.

And maybe could withScope and tags could solve it?

function query() {
  try {
    queryInternal();
  } catch (error) {
    Sentry.captureException(error, (scope) => {
      scope.setTag("transaction_1", true);
    });
    throw error;
  }
}

Sentry.withScope((scope) => {
  try {
    scope.setTag("transaction_2", true);
    query();
  } catch (error) {
    Sentry.captureException(error);
  }
}

In the sample the tags will be set in both cases.

[itsramiel]

The example you provided will set both tags on the error captured inside the query fn but the other capture exception is still dropped as provided in the repro but still this example is useful because you can set multiple tags and have them be captured with the error while transaction name is overriden, so it is helpful.

Let me try doing that

[krystofwoldrich]

@itsramiel Awesome, let us know if it works for you.

[itsramiel]

@krystofwoldrich Closing as it is not critical for me and I am more aware of how this works now