Exception are grouped the wrong way due to wrong stacktrace

[Jean85]

We are using 0.5 and sentry/sentry 1.5.0 in production, and we are currently seeing a strange behavior in Sentry: it's grouping together exceptions that came from very different places, just because they are the same classes (\LogicException).

I thing the culprit is the stacktrace.

Due to how Symfony is build, there is a $response = call_user_func_array($controller, $arguments); in every handled request. If do not ask to see the full stacktrace, Sentry shows only it up to that line, hiding al the code that belong to my project; I think this leads to the wrong grouping.

Screenshot

[Jean85]

Is this maybe a Sentry issue? It seem to ignore anything above the anonymous function...
Paste of the raw stacktrace (with redacted text):

LogicException: [redacted]
#8 src/Facile/[redacted].php(1312): [redacted]
#7 src/Facile/[redacted].php(885): [redacted]
#6 src/Facile/[redacted].php(304): [redacted]
#5 [Anonymous function](0): call_user_func_array
#4 app/bootstrap.php.cache(3238): handleRaw
#3 app/bootstrap.php.cache(3197): handle
#2 app/bootstrap.php.cache(3351): handle
#1 app/bootstrap.php.cache(2536): handle
#0 web/app.php(19): null

[dcramer]

Whats happening here is its not including 'src' in the app paths. Is that a common setup? If so we can add it to the defaults? Additionally, as I dont think its configurable yet, we could make it so you can specify your own app paths.

[dcramer]

Actually, I'm looking at our sample project, and I'm not sure why app path is even set to this.

[Jean85]

Yeah, that is a pretty common setup, it's how Symfony is normally installed as a full framework. Thanks for the quick fix!

I don't know if I would have included the whole project folder, maybe just the src folder could be enough? Coupled with a configurable list of paths, it would be the way to go IMHO. I'll take a look at the source code tomorrow.

[dcramer]

@Jean85 I'd bump up to 0.6.0 and see how its working for you.

One limitation right now is we dont have multiple app paths supported, only exclusionary. We could of course change that, but it was a quick fix for some other issues.

[Jean85]

@dcramer it's fine, I can push it in production right away tomorrow, and I can report back ASAP.

[Jean85]

I've just done the deploy.

First issue that comes to mind: should we exclude by default the cache folder? Normally it's app/cache for Symfony 2.x and var/cache for Symfony 3.x.
Many parts use this, mainly controllers and Doctrine's entities; I think that those parts should not be considered part of the app, since the code is autogenerated and composed mainly by dumped containers and proxy classes.

[Jean85]

OTOH, the issue seems to be fixed, the path mapping is working now!

[dcramer]

Agreed regarding the cache.

I'm wondering if this is going to cause problems:

http://symfony.com/doc/current/configuration/override_dir_structure.html

Not entirely sure how we can programmatically bind configuration based on calls like this in Symfony.

[Jean85]

In my experience this kind of override is very rare. I think that, on our side, the config is enough as it is, I would just add the cache to the defaults, as said earlier.

[dcramer]

@Jean85 looks like it might be safe to ignore var entirely?