Sentry-laravel: No ability to disable sentry on local env

[deniskoronets]

This package automatically injects sentry into logging services, there is no ability to turn it off for local environment.

[stayallive]

On what version of sentry-laravel are you?

injects sentry into logging services

Are you referring to us registering a log channel called sentry or something else?

We are aware we listen to more events than we should (without a DSN set) and that is being addressed in #205.

[deniskoronets]

I'm on laravel 5.7, sentry-laravel 1.0.0.

I'm saying that after install, autodiscover injects your provider: src/Sentry/Laravel/ServiceProvider.php
which registers sentry logger with no option to disabled it by some flag in config/sentry.php:

        if (($logManager = $this->app->make('log')) instanceof LogManager) {
            $logManager->extend('sentry', function ($app, array $config) {
                return (new LogChannel($app))($config);
            });
        }

On my local, I dont want to track errors but there is no option to disable sentry logging for particular env.
It would be nice to add some key into config/sentry.php like '_logger' => [ 'enabled' => false ] so it'll be removed before passing param to sentry itself, but it will configure logger.

[deniskoronets]

Actually wait. Something weird happens. I have such code on my local:
```
if (getenv('APP_ENV') != 'local'
&& app()->bound('sentry')
&& $this->shouldReport($exception)
) {
app('sentry')->captureException($exception);
}

In case of usual exception, thrown from my custom controller it hasnt pass to sentry because of my IF statement. But if I make something with routes.php:

});

1

Route::group(['middleware' => 'auth'], function() {
```
(syntax error),
somewhy it goes to be logged into sentry.

I guess it is some different error handler which forces exception to be sent. (not app's Exceptions\Handler)

[stayallive]

Ah, this I can explain :)

Since we do register the Sentry client in the container it listens for uncaught and fatal errors (they won't pass through the Laravel exception handler since it's, well.. a fatal error halting execution).

If you set the SENTRY_LARAVEL_DSN in you .env locally to null or remove it, Sentry might record it internally but never sends it out because the DSN is missing so nowhere to sent it to.

Would this solve your issue?

[deniskoronets]

I think this should be mentioned as a part of documentation, in manner like "we recomment to use null dsn in case local environment in order to disable error handling".
I though that null dsn will broke the app.

[stayallive]

I opened a PR to the docs to add this: getsentry/sentry-docs#803.

[tobiaseisenschenk]

Ah, this I can explain :)

Since we do register the Sentry client in the container it listens for uncaught and fatal errors (they won't pass through the Laravel exception handler since it's, well.. a fatal error halting execution).

If you set the SENTRY_LARAVEL_DSN in you .env locally to null or remove it, Sentry might record it internally but never sends it out because the DSN is missing so nowhere to sent it to.

Would this solve your issue?

Note: This does not work with all sdks. Maybe wrong repo but for example the react-native sdk can not take a dsn of null

[stayallive]

This repo is specifically for the Laravel Sentry integration and the comment above is true for this one (documentation was also only updated for Laravel). So if you would like to see this in other SDK's you'll need to open an issue there 😄

[InstanceOfMichael]

How would you disable sentry for the remaining duration of one specific artisan command?

[stayallive]

@InstanceOfMichael there are a few ways you could do this, none are very pretty though... the beste way would be to actually capture any events before Sentry can handle them by using a try/catch for example or to never enable Sentry in the first place.

I am very interested in the use case for this though...

This is an example using the sample_rate option to effectively disable Sentry.

public function handle()
{
    /** @var \Sentry\State\HubInterface $sentry */
    $sentry = app('sentry');

    $sentry->captureException(new \Exception('Just testing1'));
    $this->info('Latest ID: ' . $sentry->getLastEventId()); // some event id

    // Set the sample rate to 0 effectively disabling event sending
    $sentry->getClient()->getOptions()->setSampleRate(0);

    $sentry->captureException(new \Exception('Just testing2'));
    $this->info('Latest ID: ' . $sentry->getLastEventId()); // empty

    // Reset the sample rate back to the default (1)
    $sentry->getClient()->getOptions()->setSampleRate(1);

    $sentry->captureException(new \Exception('Just testing3'));
    $this->info('Latest ID: ' . $sentry->getLastEventId()); // some event id
}

In this example Just testing2 will never be sent to Sentry.

[briedis]

Yeah, I would like to disable Sentry too if the .env file does not contain a value.
Feel kinda weird that Sentry error handler catches all my exceptions even if I don't want to use it (for example, when running phpunit).

Apparently the service providers are auto-discovered and loaded automatically.

I would imagine if I edit config/sentry.php I could forcefully disable Sentry's error handler registration, but even if I return empty array in that file, Sentry be like whatever, I'm gonna catch things anyway.

[stayallive]

@briedis this is already somewhat the case. If you leave the value in your .env empty Sentry is never actually sending events. See also: https://docs.sentry.io/platforms/php/laravel/#local-development. It's still registered because you are able to set the DSN later if you wanted to or just not care if Sentry is active or not without having to do a if (app()->bound('sentry')) guard each time you want to interact with Sentry directly. There are several pro's and con's to this ofcourse.

You can opt-out of package discovery (scroll to "Opting Out Of Package Discovery") and register the service provider yourself if needed.

If you feel like this is unacceptable please open up a new issue so we can discuss this further and hear your arguments and/or proposed solutions but I believe the above 2 solutions (empty .env value or opting out of package discovery) are some valid options to disable Sentry locally.