[🐛]: Invalid DSN locks site into broken state

[edward-simpson]

What is the current behavior?

Omitting the protocol from the DSN (which is valid) causes this DSN to get cached. Every site load or CLI usage tries to use this cached value, which then fails validation, this means there's no way to flush the cache (bar wiping files/manually flushing redis) after correcting the DSN

What is the expected behavior?

An invalid DSN format should not error out the whole site, and especially not the CLI

How can we reproduce the issue?

Omit the protocol (https://) from the DSN - either in the env.php or the admin panel override

What is the proposed solution?

Relax the DSN validation, and disable the module functionality if the config is not valid

do you have any additional information for us?

I'm willing to write a fix if you let me know what your preferred solution would be

Is there an existing issue for this?

• I have searched the existing issues

Are you willing to create a pull request for this?

• If i have a fix i would be willing to create a pull request

[indykoning]

Unfortunately the https:// is necessary, the Sentry SDK needs it. We don't have control over that.
However the application must never crash when configuration is incorrectly entered.
We should probably disable sentry with some kind of message somewhere if it is missing the http(s)

[edward-simpson]

@indykoning ah I thought my other Sentry usages omitted the protocol but looks like they also include it! I'd recommend some admin panel validation too, to prevent a non developer entering a malformed value, which would then need a developer to fix and clear cache

[indykoning]

Yes i agree, and we already have a function to achieve this

magento2-sentry/Helper/Data.php

Line 377 in eeb9470

if (!$dsnNotEmpty && !$this->isSpotlightEnabled()) {

We should probably add the check here. A reason here will block activation of the module, and the send test event button will return the reasons why it's not active