Wrong stack trace when using in-app middleware about sentry-laravel HOT 6 CLOSED

This is probably because the exception is caused by framework code and not triggered by your own. You are showing an example for a relation not found error triggered by Eloquent, it's really hard to know why or what is actually triggering the error from your screenshots though.

By default we mark only code in your app folder as "in app". This causes the stacktrace in Sentry to be collapsed and only frames from your application code are highlighted unless you open the full stack trace.

So the stack trace is "correct", but for some errors no code from your own application is triggering the actual error causing these kind of stack traces.

Anyway, I'm not sure it makes sense what I am saying but the stack trace is correct, it's just a little confusing in this specific instance.

from sentry-laravel.

Stack trace is correct on both screens, but in "Expected result" is more accurate. In this case, Laravel Nova used relation that does not exist, so actually no app code was executed.

In cases like that, Sentry indicates on first in-app code that was included in stack-trace and in most cases it will be Middleware, because they participate in every requests.

This can be confusing, but, as I think now, probably there is no better method. Maybe middlewares should not be "Most relevant" if they are not causing error directly?

I'm also not sure if it's the responsibility of this package.

from sentry-laravel.

Yeah I totally get what you are saying. I'm not sure there is a good way for us to solve this though. I understand the "Most Relevant" here is misleading but it's also not because of the way middlewares work and your code is usually the most relevant...

Maybe we should exclude middlewares as in-app frames although currently I don't think that is very easy to do. This is because in_app_include (where we add app/) takes precedense over in_app_exclude (where we could add app/Http/Middleware/): https://docs.sentry.io/platforms/php/guides/laravel/configuration/options/#in-app-exclude.

We obviously also don't want to modify the stacktraces too much to prevent us inadvertently messing them up or making them factually incorrect which would be even more bad.

But in these cases where you have a lot of logic in a vendor package the in app frames are meh. Maybe you could add vendor/laravel/nova/ to in_app_include to make the stacks from errors in Nova a little more clearer for you.

from sentry-laravel.

Can we made in_app_include and in_app_exclude configurable from sentry.php? I'm thinking about removing app/ from in_app_include and leaving it blank or making it more precise like app/Controllers, app/Models etc.

Generally in_app_exclude should have precendence over in_app_include, it makes more sense and would be more flexilbe.

from sentry-laravel.

They are, just add them 😉

Edit: This is our default, we only define the exclude by default (and you can override this by adding the key to config/sentry.php yourself if you need to):

So I was wrong by saying we define app/ as in_app_include instead we exclude the vendor directory, so you can add for example vendor/laravel/nova to in_app_include and it would show frames from Nova as in-app while keeping the rest of you vendor folder excluded (assuming you don't change in_app_exclude).

So you could do something like this for example:

	'in_app_include' => [
		base_path('/vendor/laravel/nova'), // if you want Nova to show up as in-app frames
	],
    'in_app_exclude' => [
		base_path('/vendor'), 
		base_path('app/Http/Middleware'), // to exlcude middleware from showing as in-app frames
	],

from sentry-laravel.

As @stayallive wrote, this can be easily customised on the app level, using in_app_include/in_app_exclude. I don't think it's feasible to change any defaults.

from sentry-laravel.