sentry-symfony: Causes too many database connections via behat.

Environment

How do you use Sentry? Sentry SaaS

Which SDK and version? 3.10 SDK bundle 4.0.1

Steps to Reproduce

  1. composer require sentry/sentry-symfony
  2. Accept recipe
  3. add in the following sentry config
sentry:
    dsn: '%env(SENTRY_DSN)%'
    options:
        environment: '%kernel.environment%'
        integrations:
            - 'Sentry\Integration\IgnoreErrorsIntegration'
services:

    Sentry\Integration\IgnoreErrorsIntegration:
        arguments:
            $options:
                ignore_exceptions:
                    - Symfony\Component\HttpKernel\Exception\NotFoundHttpException
                    - Symfony\Component\Security\Core\Exception\AccessDeniedException
                    - Symfony\Component\Security\Core\Exception\AuthenticationCredentialsNotFoundException
  1. Commit and push to bitbucket
  2. Bitbucket pipeline runs.

Expected Result

Behat passes normally

Actual Result

Behat fails half way through with every test resulting in the same error

  ╳  PDOException: SQLSTATE[08006] [7] FATAL:  sorry, too many clients already in vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:38

Note

It may be useful to know I have two dbal connections one for MySQL and one for TimescaleDB which uses the postgres driver and it’s the timescaledb that is failing.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 16 (3 by maintainers)

Most upvoted comments

I had to manually add a dependency this bundle has

I’m pretty sure your issue is the same as #379, which is not a fault of this bundle but rather an unfortunate consequence of having installed the SensioFrameworkExtraBundle bundle which expects the nyholm/psr7 package to be installed without requiring it in its composer.json when the HttpFoundationFactoryInterface interface exists. This problem causes applications to break as soon as something else requires symfony/psr-http-message-bridge, which is the package providing that interface, and it’s gonna be solved in version 6.0 of that bundle.


Some parts of this comment were redacted as off-topic.

@Jean85 gracefully donates a lot of his time into contributing to this library and I find the tone of the conversation here to be unnecessarily confrontational towards him.

His comments on the nature of the issue I believe are entirely correct and I’m not sure there is anything actionable here. I’m inclined to close this issue and direct you towards the support in the app. There the issue will be triaged by the support team and escalated accordingly.

I’m closing this because there are no enough information to reproduce this issue, and because I strongly believe it doesn’t really depends on us. Should you have more information or should you be able to exactly pinpoint the issue feel free to reopen it back

No, I don’t feel personally attacked by “thruths”. I feel personally attacked when you say something like

this bundle somehow drops the database connection without closing causing too many connections.

You’re implying that the issue lies in this bundle that, since it’s largely written by me, I know very well, and that’s because I’m says that the cause is probably indirect and due to your project setup and/or the error handler, which isn’t even on this repo, but on a related one.

Meanwhile, you’re still dismissing:

  • the requests for further details and/or investigations to pinpoint the issue
  • the requests to ask for commercial support on the proper avenues
  • the remarks made by @dcramer and me (I found the Twitter thread just now), that underlines the fact that this GitHub repo is for the OSS part of it

If you want to have a paid-level of support, you shouldn’t insist on asking for it here. If you insist on asking for it here, you’re stuck with me and a best-effort response.

And in any case, you have to provide us with more details, or me nor the paid support we’ll be never able to solve it.

I’ll no longer reply if not provided with more technical details.