Sentry-php: [1.x] Duplicate errors

[joshlewis]

This issue seems related to #408.

I'm getting two errors logged in Sentry for one error happening in my app. We're using php 5.6.31. I'm demonstrating this error by just purposefully throwing a standard Exception in a controller with a made-up error message. Here's a screenshot of the Sentry issue queue showing the duplicates:

It looks like one of them is the "real" error, and one of them appears to be an error _about_ the error. The good one contains helpful metadata, and the secondary one contains the stack trace captured by the first in a string, and shows vendor/sentry/sentry/lib/Raven/ErrorHandler.php as #0 in the stack trace.

The good error says "Exception /dashboard/boost/all/cbhomes in system/application/controllers/dashboard/boost.php
This is a Sentry event for Mark to see."

The unwanted secondary error says "ErrorException /dashboard/boost/all/cbhomes
in system/application/controllers/dashboard/boost.php
Uncaught exception 'Exception' with message 'This is a Sentry event for Mark to see.' in /var/www/html/system/application/controllers/dashbo..." and it continues by showing the stack trace from the good error in plain text as part of the error message itself.

[Jean85]

Are you using any official integration, like the Symfony bundle? Or just the base SDK client?
Do you have any other packages installed that wire up an error handler?

[joshlewis]

I'm using an older version of CodeIgniter.

So does this mean that I need to de-register all other error handlers, or what's the recommendation?

[mfb]

One of these is the exception, and the other is the fatal error that PHP reports when there is an uncaught exception.

If your app has an exception handler to catch the exception after Sentry captures it (and do whatever is appropriate such as print a nice error page with HTTP 500 status code) then it won't be uncaught. Otherwise the fatal error comes into play.

It's important for Sentry to capture some fatal errors (such as memory limit); others are ignored via logic in Raven_ErrorHandler::shouldCaptureFatalError().

[joshlewis]

Did some more digging and discovered that on PHP 7, with no other pertinent code changes, the uncaught exception is silenced and what I've called the "real" exception still gets logged. Which is good!

I'm guessing this has to do with the explicit PHP_VERSION_ID check in shouldCaptureFatalError(), and also the expectation that the uncaught exception message is formatted using PHP 7's style.

In PHP 7, the format is the one shouldCaptureFatalError() looks for:

Uncaught Exception: Some error message here

But in PHP 5.6 (and possibly earlier versions), the format of the same error is like this instead:

Uncaught exception 'Exception' with message: 'Some error message here'

Do you think there's a way this could be tweaked so that the same desired silencing effect can be had on PHP 5.6, and potentially even earlier?

[bimimicah]

I've made a pull request (#830) with the code we're using to fix this issue.

[Spriz]

It seems like these methods have been removed in 2.x - what have you done here to prevent this issue?

[bimimicah]

This is a patch for a 1.x/raven-php bug.

[Jean85]

@Spriz the issue here is due to nested error handlers in PHP. We fixed it altogether in 2.x, and it's not easy to fix due to the fact that any nested handler can manipulate the error, and make the fix unuseful.

[bimimicah]

Regardless, for the vast majority of cases where this appears (unmanipulated exceptions) the fix is still useful on PHP5. And it does (functionally) the same thing as the code path for PHP7, so it's a version parity issue between the PHP 5 and PHP 7 code paths in version 1.x. It would be nice to see the fix merged so we can move closer to using the official distribution again. Please don't forget that PHP5 is supported on enterprise systems (RHEL7,CentOS7) for several more years yet. Thank you for your time.