Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

How to know event has successfully captured?

See original GitHub issue

Hello, we are trying to switch to this new sentry client from raven-sharp, but it seems some functionallity is missing. In raven-sharp was possibility to know that event captured successfully or not. For that we used RavenClient.Send() which returns non-empty string on success. Is there a way to know this with sentry-dotnet? P.S. This needed for ensuring all events will be captured (even if app restarts when e.g. was no internet connection). We cache all failed event to file, and re-send them on next app start.

Issue Analytics

State:
Created 3 years ago
Comments:8 (4 by maintainers)

Top GitHub Comments

1reaction

CADblokecommented, Jun 29, 2020

You could implement the diagnostic logger, it logs when an event has been successfully received, queue depth etc. . See https://github.com/getsentry/sentry-dotnet/issues/185#issuecomment-486726027

Here’s a sample of the output from my Serilog file for the Diagnostic logger …

[v1.1.2901.20181] 13:05:51.062 -   Debug: Initializing Hub for Dsn: 'https://<redacted>@sentry.io/<redacted>'. 
[v1.1.2901.20181] 13:05:51.086 -   Debug: Using 'GzipBufferedRequestBodyHandler' body compression strategy with level Optimal. 
[v1.1.2901.20181] 13:05:51.094 -   Debug: Registering integration: 'AppDomainUnhandledExceptionIntegration'. 
[v1.1.2901.20181] 13:05:51.099 -   Debug: Registering integration: 'AppDomainProcessExitIntegration'. 
[v1.1.2901.20181] 13:05:51.108 -   Debug: New scope pushed. 
[v1.1.2901.20181] 13:05:54.572 -    Info: Capturing event. 
[v1.1.2901.20181] 13:05:54.589 -   Debug: Running main event processor on: Event 9a85161fb80842859474e652cd367b84 
[v1.1.2901.20181] 13:05:54.607 -   Debug: Creating SentryStackTrace. isCurrentStackTrace: True. 
[v1.1.2901.20181] 13:05:54.629 -   Debug: Event queued up. 
[v1.1.2901.20181] 13:05:54.722 -   Debug: Event <redacted> in-flight to Sentry. #1 in queue. 
[v1.1.2901.20181] 13:05:55.690 -   Debug: Event <redacted> successfully received by Sentry. 
[v1.1.2901.20181] 13:07:42.863 -    Info: Disposing the Hub. 
[v1.1.2901.20181] 13:07:42.869 -   Debug: Disposing SentryClient. 
[v1.1.2901.20181] 13:07:42.873 -   Debug: Disposing BackgroundWorker. 
[v1.1.2901.20181] 13:07:42.878 -   Debug: Shutdown scheduled. Stopping by: 00:00:02. #0 in queue. 
[v1.1.2901.20181] 13:07:42.882 -    Info: Exiting the worker with an empty queue. 
[v1.1.2901.20181] 13:07:42.887 -   Debug: Disposing scope. 
[v1.1.2901.20181] 13:07:42.891 -   Debug: Disposing SentryScopeManager.

0reactions

bruno-garciacommented, Apr 25, 2020

@mogikanin if you need to “block” while an event is flushed out, you can use SentrySdk.FlushAsync.

@kanadaj that’s true, they can always hook through ISentryHttpClientFactory if needed.