For error thrown inside EventProcessor the trace is long and the original error is gone

[jrencz]

• Review the documentation: https://docs.sentry.io/
• Search for existing issues: https://github.com/getsentry/sentry-javascript/issues
• Use the latest release: https://github.com/getsentry/sentry-javascript/releases
• Provide a link to the affected event from your Sentry account

Package + Version

• @sentry/browser
• @sentry/node
• raven-js
• raven-node (raven for node)
• other: https://browser.sentry-cdn.com/5.18.1/bundle.min.js

Version:

5.18.1
First noticed in 5.15.5
Supposedly started in 5.12.4

Description

I recently started experiencing errors like this one: https://sentry.io/organizations/wongapl/issues/1749564756
I reached customer support and they inspired me to find and fix the cause: I had an EventProcessor defined like this:

Sentry.configureScope(function (scope) {
  scope.addEventProcessor(function (event) {
    return event.message.match(/some regex/) ? null : event;
  });
});

Obviously the problem was that not every event has a message and I fixed that. The error is gone.

The issues started when I updated SDK from 5.12.1 to 5.15.5.
I dug through issues and PRs and I think the error thrown in EventProcessor started appearing because of #2416 released in 5.12.4

But my problem I want to report is not that there was an error - that's actually good there was one.

But look into the trace it gives:

TypeError: a.message is undefined
  at ? (/%20line%204454%20%3E%20scriptElement:1:98)
  at executor(../../hub/src/scope.ts:100:24)
  at handler(../../utils/src/syncpromise.ts:30:7)
  at _notifyEventProcessors(../../hub/src/scope.ts:94:12)
  at executor(../../hub/src/scope.ts:106:16)
  at handler(../../utils/src/syncpromise.ts:30:7)
  at _notifyEventProcessors(../../hub/src/scope.ts:94:12)
  at executor(../../hub/src/scope.ts:106:16)
  at handler(../../utils/src/syncpromise.ts:30:7)
  at _notifyEventProcessors(../../hub/src/scope.ts:94:12)
  at executor(../../hub/src/scope.ts:106:16)
  at handler(../../utils/src/syncpromise.ts:30:7)
  at _notifyEventProcessors(../../hub/src/scope.ts:94:12)
  at executor(../../hub/src/scope.ts:106:16)
  at handler(../../utils/src/syncpromise.ts:30:7)
  at _notifyEventProcessors(../../hub/src/scope.ts:94:12)
  at applyToEvent(../../hub/src/scope.ts:344:17)
  at _prepareEvent(../../core/src/baseclient.ts:298:22)
  at _prepareEvent(../src/client.ts:69:18)
  at executor(../../core/src/baseclient.ts:386:12)
  at handler(../../utils/src/syncpromise.ts:30:7)
  at _processEvent(../../core/src/baseclient.ts:385:12)
  at method(../../core/src/baseclient.ts:132:10)
  at _invokeClient(../../hub/src/hub.ts:73:27)
  at captureEvent(../../hub/src/hub.ts:218:10)
  at handler(../src/integrations/globalhandlers.ts:103:20)
  at triggerHandlers(../../utils/src/instrument.ts:101:7)
  at yn/ln.onerror(../../utils/src/instrument.ts:497:5)

There's a lot happening in here - the error goes through SDK multiple times.

I prepared a Pen with this example: https://codepen.io/jrencz/pen/gOPoOjm?editors=0010

The traces the same for latest version and for 5.15.5 I use in prod env right now.
For versions prior to 5.12.4 nothing is sent to Sentry
Since 5.12.4 - the error thrown inside EventProcessor is sent

Another problem is that the original cause that made the EventProcessor run is gone.

[kamilogorek]

There's a lot happening in here - the error goes through SDK multiple times.

It goes through all event processors, which includes all of our integrations, that's why the stacktrace looks like this. There's not much we can do about that with the current implementation, unfortunately.

Another problem is that the original cause that made the EventProcessor run is gone.

The original error itself? It's because if we'd stash it somewhere and try to send it again, it'd cause an infinite loop with the error that occurs in the processor. The only solution to this would be to either send it raw, or disregard "broken" processor, but it can be too intrusive and not expected in most cases. There's definitely a way to improve it though.

[kamilogorek]

Closing the issue as a part of large repository cleanup, due to it being inactive and/or outdated.
Please do not hesitate to ping me if it is still relevant, and I will happily reopen and work on it.
Cheers!