sentry-php: Ignored exceptions are still built

I have a microservice that calls an external API. Sometimes, this external API will timeout, and my application will create a GatewayTimeoutException, with a NoResponseException as previous exception, with a Http\Client\Exception\NetworkException as previous exception, with a GuzzleHttp\Exception\ConnectException. It’s 4 level deep.

I found that a lot of time was spent handling those in Sentry, so I added them to the list of ignored exceptions. This did not result in an improvement, because it seems the exceptions are still handled by Sentry, even if they are ultimately not sent to the server. I mitigated the issue by not setting the NoResponseException as a previous exception when not in debug mode, it resulted in a 100ms improvement. I won’t share the blackfire trace because I can’t redact things in it, but here is a screenshot of the interesting part, which does not involve code in my application:

Screenshot_2020-05-13 Comparison from Untitled to Untitled - Blackfire

Using

sentry/sdk                          2.1.0   This is a metapackage shipping sentry/sentry with a recommended http client.
sentry/sentry                       2.3.2   A PHP SDK for Sentry (http://sentry.io)
sentry/sentry-symfony               3.5.1   Symfony integration for Sentry (http://getsentry.com)

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 18 (10 by maintainers)

Most upvoted comments

Yes, excluded_exceptions option is not being unsetted and thus both the legacy code and the new integration get executed: it’s a bug and should be fixed

Woops, my bad, yes, that’s a bug! I’ve opened https://github.com/getsentry/sentry-symfony/issues/345 to track this.

Here you go:

composer config repositories.ste93cry vcs https://github.com/ste93cry/sentry-php
composer require sentry/sentry "dev-feature/add-frame-contextifier-integration as 2.3.2"

So I suppose it’s as if I have both the option and the integration enabled?

Yes, excluded_exceptions option is not being unsetted and thus both the legacy code and the new integration get executed: it’s a bug and should be fixed

I don’t fully understand what this done

While in the documentation it was mentioned that the context_lines option would have accepted null value to skip sending the source code of the frames of the stacktrace in reality it never worked, so I fixed it.