You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
sentry_debug!("Failed to send envelope: {}", err);
If the off-by-default feature debug-logs is not enabled, then this won't get logged at all unless Sentry is configured with ClientOptions.debug = true (also off-by-default).
The TransportThread used for sending messages uses a channel with a size of 30. If this size is exceeded, then events will be dropped (with the same debug-logging issue as above):
When using Sentry in production, it can be critical that any errors are either reported to sentry, or trigger some kind of error/panic indicating that an event was not reported.
It would be very useful for Sentry to:
Log these kinds of messages as errors, rather than off-by-default debug messages
Provide the ability to use an unbounded channel (or use an unbounded channel for error/exception events), to prevent events from getting dropped in the first place
The text was updated successfully, but these errors were encountered:
There is also the possibility of this being dropped in the transport due to rate limits and some such.
Ideally, all the capturing methods would a Future that resolves to a descriptive enum with various variants for the different reasons a message/exception might be lost.
However, that would be quite deep change to how things are working right now, and would require lots of effort to make happen.
I don’t think the idea of an unbounded channel, or different channels for different event types makes sense. The transports are completely agnostic to that, as they are only dealing with opaque envelopes.
Environment
sentry v0.31.5
Steps to Reproduce
There are multiple ways that Sentry can silently lose error events:
sentry-rust/sentry/src/transports/reqwest.rs
Line 99 in 10c5640
If the off-by-default feature
debug-logs
is not enabled, then this won't get logged at all unless Sentry is configured withClientOptions.debug = true
(also off-by-default).sentry-rust/sentry/src/transports/tokio_thread.rs
Lines 88 to 93 in 10c5640
Expected Result
When using Sentry in production, it can be critical that any errors are either reported to sentry, or trigger some kind of error/panic indicating that an event was not reported.
It would be very useful for Sentry to:
The text was updated successfully, but these errors were encountered: