Closed helloiamlukas closed 8 months ago
Hi @helloiamlukas
Are you registering your callback for Sentry based on the Laravel 8 exception handler?
Using the Sentry docs you are supposed to register it within a reportable
callback inside the register
method of your Exception handler.
@jelleroorda This problem is not only related to Sentry.
But yes, I also tried to registering the callback as in the Sentry docs (and the Laravel 8 exception handler). Doesn't work.
I've checked why, and it turns out that there's a middleware that swaps out the exception handler for a ApiExceptionHandler. I'm not completely sure why that was done though. The only thing I can see is that it might have something to do with testing.
For now you can work around it by adding something like this in your AppServiceProvider@boot
method:
$this->app->resolving(\Illuminate\Contracts\Debug\ExceptionHandler::class, function($handler) {
$handler->reportable(function(\Throwable $e) {
dd('exception', $e);
});
});
It'll register your reportable handler for both exception handlers. Maybe @jasonvarga has a better solution or can explain why we need the ApiExceptionHandler?
@jelleroorda Good catch!
I would be also interested in why the exception handler has been swapped out. @jasonvarga please give us some insight 👨💻
Okay, I found something in the commit message https://github.com/statamic/cms/commit/9be827c449ee95cda697eafe9f3d39c470029a0e
Swap the exception handler in a middleware, since in a service provider we don't have access to the request and it would be too early to conditionally rebind.
Since it's in a middleware, it'll only use that exception handler (and thus handle the json 404 responses) when it actually hits a real route. Added a wildcard 404 route to the API like we have in the CP.
From what I can see, maybe we could take this api rendering part and add it in the NotFoundHttpException@render method inside a manual check for whether it's an api route. Statamic::isApiRoute()
wouldn't work since it doesn't handle the StatamicProAuthorizationException
use case (it returns false if pro is disabled).
Let's wait for Jason for now 😄
It was done so that we could control responses for CP and API errors. So yes if we can continue to use the appropriate responses without using our custom handlers... we can avoid swapping the handlers.
Bug description
I came across some exception that will be ignored by the
app\Exceptions\Handler.php
and will be directly handled byIlluminate\Foundation\Exceptions\Handler
.Therefore logging to external services (e.g. Sentry) will not work.
I don't know if this is Statamic specific or is a problem related to Laravel, but I thought I'm gonna open an issue so you can have a look.
How to reproduce
statamic/starter-kit-starters-creek
statamic instance.config/statamic/api.php
/api/collections/blog/entries?filter[date:is_past]=abc
app\Exceptions\Handler.php
:/api/collections/blog/entries?filter[date:is_past]=abc
againdd()
will be ignored.Logs
Versions
Statamic 3.2.10 Pro Laravel 8.62.0 PHP 7.4.24 statamic/ssg 0.8.0
Installation
Starter Kit using via CLI
Additional details
statamic new mysite statamic/starter-kit-starters-creek