Sentry did not raise any error msg / issue upon not being able to connect to Sentry API

[UnitTHK]

How do you use Sentry?

Self-hosted/on-premise

Version

2.15.0

Steps to Reproduce

Simply having a connection issue between Sentry SDK and Sentry
In my case it's not having a proper route to Sentry

Expected Result

An error / warning message to show up

Actual Result

Nothing shows up at all to tell me that Sentry weren't able to connect. The only reason I figured out that there's a connectivity issue is when I triggered debug logging and urllib actually warned about it

[sentrivana]

Hey @XxTHKxX, thanks for writing in. In general, we're trying to limit the amount of non-debug-level logs as much as possible. The reason is that we don't want to spam folks' logs since an intermittent issue could end up burning through their logging quota/increasing their logging costs.

The trade-off is that it's harder to notice when something like this happens. In your case, was this an issue with the DSN not being set up correctly from the start or a temporary connection issue once everything was up and running?

[UnitTHK]

Heya, so for me, it's a bit of a edge case, the Sentry self hosted machine is on a ipv6 only network, while the docker container hosting the service that are using sentry are misconfigured to only use ipv4, causing the connection issue, a reconfiguration of the docker default bridge network fixed the issue but it'd really be helpful to know of these connection issue as a proper error msg, instead of only a warning msg that urllib raised (and even that one requires me tuning up the logging level from default to logging.warning to even see! By default nothing is ever printed or raised, even after 4 connection failure) Best regards THK

…

On Oct 8, 2024, 3:18 PM +0700, Ivana Kellyer ***@***.***>, wrote: Hey @XxTHKxX, thanks for writing in. In general, we're trying to limit the amount of non-debug-level logs as much as possible. The reason is that we don't want to spam folks' logs since an intermittent issue could end up burning through their logging quota/increasing their logging costs. The trade-off is that it's harder to notice when something like this happens. In your case, was this an issue with the DSN not being set up correctly from the start or a temporary connection issue once everything was up and running? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[sl0thentr0py]

There have been talks of an initial init-phase health check (for remote config) so that would also help cases like these. I'll keep this open as a backlog item for whenever we do that.