twine-net / raven-php Goto Github PK

The way our API works, certain exceptions are ok to throw, and the proper response bubbles back up to our client.

An example of this would be Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException Invalid email or password

Can you recommend how I should go about preventing AccessDeniedHttpException from being reported to sentry? Not sure if I should do it manually in app/Exceptions/Handler.php or a configuration deeper in sentry/sentry

Thanks

When running Log::error($exception) with an Exception object (which is what the default error handler does, such as during an unhandled exception) an exception is logged to Sentry with a message like Exception: test exception 2 in /home/vagrant/sparkit/routes/web.php:15 Stack trace: #0 /home/vagrant/sparkit/vendor/laravel/framework/src/Illuminate/Routing/Route.php(176): App\Providers\RouteServiceProvider->{closure}() #1 /home/vagrant/sparkit/vendor/laravel/framework/src/Illuminate/Routing/Route.php(147): Illuminate\Routing\Route->runCallable() #2 /home/vagrant/sparkit/vendor/laravel/framework/src/Illuminate/Routing/Router.php(642): Illuminate\Routing\Route->run(Object(Illuminate\Http\Request)) #3 /home/vagrant/sparkit/vendor/laravel/framework/src/Illuminate/Routing/Pipeline.php(53): Illuminate\Routing\Router->Illuminate\Routing\{closure}(Object(Illuminate\Http\Request)) #4 /home/vagrant/sparkit/vendor/laravel/framework/src/Illuminate/Routing/Middleware/SubstituteBindings.php(41): Illuminate\Routing\Pipeline->Illuminate\Routing\{closure}(Object(Illuminate\Http\Request)) #5 /home/vagrant/sparkit/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(137): Illuminate\Routing\Middleware\SubstituteBindi. Presumably this is a truncated form of $exception->__toString().

Can the Monolog handler instead detect an Exception instance and deal with it properly?

This would allow exceptions to be logged directly, which both makes things easier for developers and allows the default Laravel exception handler to log exceptions to Sentry properly.

Hello,

Package raven/raven is abandoned, you should avoid using it. Use sentry/sentry instead.

I started to get this

The readme suggests configuring Laravel to log uncaught exceptions and then call parent::report on the exception too.

But the parent report method also logs the message. This means it gets reported twice.

They are reported with different messages, which I'll talk about in a different ticket.

It seems to me it would be better not to suggest adding anything to the report method at all, and have it logged just once.

When I look at the submitted issues in the Sentry interface, they all have a JSON-encoded representation of the context data after the message, such as test warning {"user":{"id":1,"email":"[email protected]"}} []. This particular issue was logged with \Log::warning('test warning');, with context added via a processor. I get the same result if instead of the processor I add the context data as you do in the example in the readme.

If I look at the JSON submitted to Sentry I see that this JSON-encoded context data is present in the message string. It seems to me this should not be there.

Just a heads up: I tested with the latest dev version of Monolog just now and had this error:

Declaration of Twine\Raven\Logger::addRecord($level, $message, array $context = Array) must be compatible with Monolog\Logger::addRecord(int $level, string $message, array $context = Array): bool in /Users/bart.nagel/src/sparkit/vendor/twineis/raven-php/src/Logger.php on line 28

Looks like they've added typing.

The config file shows how to add Monolog processors, and gives an example of a GitProcessor. Whether I add this one or my own UserDataProcessor or other Monolog processors such as MemoryUsageProcessor, they do not run and so their data is not attached to the messages passed to Sentry.