Causes too many database connections via behat.

[that-guy-iain]

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

4. Commit and push to bitbucket
5. 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.

[that-guy-iain]

This also happens on 3.5.8.

[Jean85]

The issue seems to be raised from PDO itself, since PDOConnection.php:38 is a call to parent::__construct. Doesn't seem to me something related to Sentry, but maybe only triggered by its installation.

Maybe you have some connection limitation in your DB?

[that-guy-iain]

The connection issue will come from Postgres/Timescale. However, it is only caused when I installed the sentry bundle. Literally, the only change made was enabling the sentry bundle and the error arrived and when I removed it the error left. It seems logical that somehow the sentry bundle is interacting with Doctrine/Dbal/PDO in a way that causes it to lose a connection and regenerate a new one.

[Jean85]

That's not the only possible interaction; adding a new bundle could heavily shape how the DI container is dumped, hence creating the possibility for a trigger (but not a direct cause) of this issue.

Citing a fast search: https://www.enterprisedb.com/blog/postgresql-pgpool-connection-pool-database-load

Simply put, this error appears when the number of clients connected to the database exceeds the concurrent limit max_connections defined in the postgresql.conf file.

So, you're connecting too many times. Are you sure that your container is not over-instantiating its client multiple times? Or not sharing the instances?

[that-guy-iain]

That's not the only possible interaction; adding a new bundle could heavily shape how the DI container is dumped, hence creating the possibility for a trigger (but not a direct cause) of this issue.

No that is the only interaction. Well, I did have to raise the PHP memory limit because of the memory usage caused by this bundle. Oh, and I had to manually add a dependency this bundle has. Overall, I tried to use this bundle and encountered 3 separate issues. The bug report is legit. I understand why you firmly believe this bundle is not the cause because it's completely nuts but sadly it is. And removing the bundle made the error go away.

[Jean85]

I'm saying that the bundle is not the root cause, but I agree that it's triggering the issue. I'm convinced that it's not the root cause since our code has no other way to interact with a database connection, so it's something a lot more complex that "your bundle has a bug". You can understand my scepticism since this is a very strange bug report, and this bundle is widely used, with no reports of such memory bloats up until now.

---

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

[ste93cry]

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.

[that-guy-iain]

I'll add my doctrine.yaml to help you guys.

doctrine:
    dbal:
        default_connection: default
        connections:
            default:
                url: '%env(resolve:DATABASE_URL)%'
            timescale:
                url: '%env(resolve:TIMESCALE_URL)%'

        # IMPORTANT: You MUST configure your server version,
        # either here or in the DATABASE_URL env var (see .env file)
        #server_version: '13'
    orm:
        connection: default
        auto_generate_proxy_classes: true
        naming_strategy: doctrine.orm.naming_strategy.underscore_number_aware
        auto_mapping: true
        resolve_target_entities:
            HumblyArrogant\Underpin\User\Entity\UserInterface: App\Entity\User
            HumblyArrogant\Underpin\User\Entity\TeamInterface: App\Entity\Team
        mappings:
            App:
                is_bundle: false
                type: annotation
                dir: '%kernel.project_dir%/src/Entity'
                prefix: 'App\Entity'
                alias: App
            Underpin_User:
                is_bundle: false
                type: annotation
                dir: '%kernel.project_dir%/vendor/humblyarrogant/underpin-bundle/src/User/Entity'
                prefix: 'HumblyArrogant\Underpin\User\Entity'
                alias: Underpin_User
            Underpin_BackOffice:
                is_bundle: false
                type: annotation
                dir: '%kernel.project_dir%/vendor/humblyarrogant/underpin-bundle/src/BackOffice/Entity'
                prefix: 'HumblyArrogant\Underpin\BackOffice\Entity'
                alias: Underpin_BackOffice

The customer entities from the bundles only use MySQL so won't use the pgsql driver which is failing.

Docker images used are php:7.4.7, mysql:latest, and timescale/timescaledb:latest-pg12

---

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

[chadwhitacre]

we're volunteers, not paid employees

Greetings, friends, paid employee here. 👋 I'm on the Open Source team, which means I have no idea about the PHP details, but I'm happy to help route this to the right place.

@iaicam Sorry for the frustration, you're right that you're in an officially supported Sentry repo, and three days is a long time to go without a proper response. We're grateful to @Jean85 @ste93cry and our other contributors, but ultimately yes it's Sentry's responsibility to stay on top of this repo. Sorry for not doing better with that, we are actively working to improve our open-source triage processes to keep up with our growth as a company and will continue striving to do better.

I'm checking with some folks internally to make sure this is routed to the right team, please stand by ...

[mitsuhiko]

@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.

[ste93cry]

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