Event confirming event submission

[ripperdoc]

What problem could Sentry solve that it doesn't?

Many times in production we've had issues with Sentry events not submitting as expected. It has been many different reasons. Many of them have been our errors in code that runs when an event is created or sent (eg event processors, attachments, beforeSend). Sometimes it's been user networking issues or Sentry outages.

What I would wish for is a simple event that I could listen to that confirms that an event has been received. I could use this to display feedback to a user after an error report or that an error was caught and reported. I currently do this in beforeSend, but that's a bit fake as it might very well fail to send after beforeSend has run. Even better if this or a related event could also trigger if Sentry knows that something went wrong during sending, so that I can handle that case in the UI (e.g. ask the user to send report again or do some additional logging).

[bitsandfoxes]

Hey @ripperdoc. I'm not sure this can be done easily. For example: While Sentry acknowledges to the SDK to have received an event, that event could then get dropped by Relay (for whatever reason) and not show up on the issues page. And Relay dropping an event is not getting communicated back to the SDK.

What I could think of as an alternative solution to your BeforeSend workaround is adding your own BackgroundWorker that takes care of actually sending the event. Similar to what we do for WebGL and "unknown platforms" here: https://github.com/getsentry/sentry-unity/blob/main/src/Sentry.Unity/UnityWebRequestTransport.cs

We might have to take another look at the Configure callback because we're overriding the BackgroundWorker after the fact, especially in those cases but would that work for you?

[bruno-garcia]

Relates to:

• https://github.com/getsentry/sentry-javascript/issues/2939
• https://github.com/getsentry/sentry-dart/issues/352
• https://github.com/getsentry/sentry-cocoa/issues/660
• https://github.com/getsentry/sentry-react-native/issues/810

[ripperdoc]

I understand it's hard to guarantee delivery status, but I'd be happy with getting at least the same information that is routed to the debug log anyway, e.g. there I would see if an event was delivered or not.

I can look into BackgroundWorker, I am using the one you just released for WebGL (after previously using a similar but hackier way of sending when on WebGL), but I am concerned of creating bugs or losing future improvements by not using your BackgroundWorker.