sentry-symfony: Sentry bundle breaks doctrine migrations.

Environment

PHP 8.0 Symfony 5.2 Doctrine Migrations 3.1 sentry-symfony 4.1

Steps to Reproduce

Having the above combination completely breaks the Doctrine migrations unless we add to each migrations a method indicating that the migration is not transactional. Doctrine had this issue before (https://github.com/doctrine/migrations/issues/1104) but they fixed it with this check:

https://github.com/doctrine/migrations/blob/96c64fa17477e503da8245f14541d70d7ae76091/lib/Doctrine/Migrations/Tools/TransactionHelper.php#L39

However, sentry decorates the connection with:

Sentry\SentryBundle\Tracing\Doctrine\DBAL\TracingDriverConnection

which is obviously not a PDO instance, so the aforementioned check fails and we get a nasty error:

In TracingDriverConnection.php line 163:
                                  
  [PDOException]                  
  There is no active transaction  

Expected Result

Well obviously I expect migrations to work with and without the sentry bundle 😃

Actual Result

In TracingDriverConnection.php line 163:
                                  
  [PDOException]                  
  There is no active transaction  

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 24
  • Comments: 32

Commits related to this issue

Most upvoted comments

You can also set sentry.tracing.dbal.enabled: false or sentry.tracing.enabled: false to disable tracing for the DBAL or completely and avoid downgrading

Right so I missed the part on the doctrine/migrations thread about adding isTransactional() { return false; } to migrations, that fixed my immediate problem

Same issue here. Looking forward to a fix! 👍

I can confirm that we can now use the latest Sentry version by adding this line to the doctrine_migrations config file:

doctrine_migrations:
    transactional: false

We don’t care about Doctrine migrations being transactional, as on MySQL DDL statements implicitly commit any active transaction anyway.

I’m gonna close this because I think there is nothing more we can do here: the original problem has been solved in Doctrine by adding a new config key (see documentation) and version 3.2.0 of doctrine/doctrine-migrations-bundle exposes it

forward the call to the decorated connection accordingly (or return null otherwise)

I tried to do this yesterday, just to find out that the return type is not marked as nullable according to the DocBlock. Instead, apparently, once you implement the interface you have to either return a value or throw an exception, which may cause issues because only specific drivers implement it and therefore are able to give back the server version. As a consequence of this, I started working on yet another decorator which implements the ServerInfoAwareConnection interface and that will wrap the instrumented connection if the original connection was implementing the aforementioned interface. Work is not finished yet, will try to find some time in the next couple of days to see if it can work

Broke our migrations and functional tests, the quick fix is a downgrade to 4.0.3!

Downgrading to : "sentry/sentry-symfony": "<4.0.9", || "sentry/sentry-symfony": "4.0.3",

works

Downgrading sentry-symfony to 4.0.3 has temporarily fixed this for me.

doctrine_migrations:
    transactional: false

did not work for us, we had to disable DB SQL Logging via

tracing:
    dbal: 
        enabled: false

in our sentry.yaml to get the migrations working again.

Otherwise we’ll get the “PDOException There is no active transaction” when running doctrine:migrations:migrate.

We are using

  • sentry/sentry-symfony 4.2.9
  • doctrine/doctrine-bundle 2.6.3
  • doctrine/doctrine-migrations-bundle 3.2.2

So this still seems to be a problem.