sentry-symfony
sentry-symfony copied to clipboard
getsentry
Deprecation warnings in 4.1.0
Environment
How do you use Sentry? self-hosted
Which SDK and version?
sentry-symfony 4.1.0 symfony 5.2.6
Steps to Reproduce
Symfony reports a couple of deprecation warnings
1x: The "Sentry\SentryBundle\Tracing\Doctrine\DBAL\TracingDriver" class implements "Doctrine\DBAL\Driver\ExceptionConverterDriver" that is deprecated.
1x: The "Sentry\State\HubAdapter::captureMessage()" method will require a new "EventHint|null $hint" argument in the next major version of its interface "Sentry\State\HubInterface", not defining it is deprecated.
1x: The "Sentry\State\HubAdapter::captureException()" method will require a new "EventHint|null $hint" argument in the next major version of its interface "Sentry\State\HubInterface", not defining it is deprecated.
1x: The "Sentry\State\HubAdapter::captureLastError()" method will require a new "EventHint|null $hint" argument in the next major version of its interface "Sentry\State\HubInterface", not defining it is deprecated.
Expected Result
no warnings
Actual Result
The last three deprecations are fixed in https://github.com/getsentry/sentry-php/pull/1206, and will be released in the next patch version of sentry/sentry.
The first one instead is tricky, and I'm not sure we can overcome it... DBAL is pretty entangled now.
The afromentioned deprecations about the HubAdapter class have been solved with the 3.2.2 version of the core SDK. The first one instead is not an easy task as of now to solve, but you can safely ignore it because we are simply implementing the methods of all versions of the interface of Doctrine and there is nothing impacting the application itself
bin/console doctrine:migrations:list -q
2021-09-20T21:12:46+03:00 [info] User Deprecated: The "Sentry\SentryBundle\Tracing\Doctrine\DBAL\TracingDriver" class implements "Doctrine\DBAL\Driver\ExceptionConverterDriver" that is deprecated.
How to suppress this error message?
We're trying something more with #553, but it's possible that those deprecations will never go away since we have to support both DBAL v2 & v3 at the same time.
But how can i suppress this message from output, when i call bin/console doctrine:migrations:list?
Is there any way to hide it from output?
I don't deeply understand how errors are handled, but i think that it's an error(notice) inside error handler, and that is why it is not handled by other error handlers and go to STD_ERR in console.
monolog:
handlers:
sentry:
type: sentry
level: !php/const Monolog\Logger::ERROR
hub_id: Sentry\State\HubInterface
php_info_filter:
type: filter
handler: php_info
accepted_levels: ["info"]
channels: ["php"]
bubble: false
php_info:
type: stream
path: "%kernel.logs_dir%/%kernel.environment%.php_info.log"
main:
type: stream
path: "%kernel.logs_dir%/%kernel.environment%.log"
level: debug
channels: ["!event"]
# uncomment to get logging in your browser
# you may have to allow bigger header sizes in your Web server configuration
#firephp:
# type: firephp
# level: info
#chromephp:
# type: chromephp
# level: info
console:
type: console
process_psr_3_messages: false
channels: ["!event", "!doctrine", "!console"]
I bet it won't, but can you please try updating to 4.2.3 and see if it solves the problem?
I don't deeply understand how errors are handled, but i think that it's an error(notice) inside error handler, and that is why it is not handled by other error handlers and go to STD_ERR in console.
It's a deprecation, so it's handled like that. Since Symfony 5.1+, there's a dedicated channel: https://github.com/symfony/recipes/blob/master/symfony/monolog-bundle/3.7/config/packages/prod/deprecations.yaml
I bet it won't, but can you please try updating to
4.2.3and see if it solves the problem?
Hi @ste93cry. Upgrading to 4.2.3 has removed the deprecation warning. I was on 4.2.2 previously.
I think that the deprecation gone because you also upgraded the doctrine/dbal package to 3.x, otherwise it doesn't make sense because we're still implementing the old interface
IIUC, the warnings should be gone in the latest 4.2.3 release, right? If yes, can we close the issue?
I'm using DBAL v2.13.2
$ composer show "doctrine/*"
doctrine/annotations 1.13.2 Docblock Annotations Parser
doctrine/cache 2.1.1 PHP Doctrine Cache library is a popular cache implementation that supports many different drivers such as redis, memcache, apc, mongodb and others.
doctrine/collections 1.6.8 PHP Doctrine Collections library that adds additional functionality on top of PHP arrays.
doctrine/common 3.1.2 PHP Doctrine Common project is a library that provides additional functionality that other Doctrine projects depend on such as better reflection support, proxies and much more.
doctrine/data-fixtures 1.5.0 Data Fixtures for all Doctrine Object Managers
doctrine/dbal 2.13.2 Powerful PHP database abstraction layer (DBAL) with many features for database schema introspection and management.
doctrine/deprecations v0.5.3 A small layer on top of trigger_error(E_USER_DEPRECATED) or PSR-3 logging with options to disable all deprecations or selectively for packages.
doctrine/doctrine-bundle 2.4.2 Symfony DoctrineBundle
doctrine/doctrine-migrations-bundle 3.1.1 Symfony DoctrineMigrationsBundle
doctrine/event-manager 1.1.1 The Doctrine Event Manager is a simple PHP event system that was built to be used with the various Doctrine projects.
doctrine/inflector 2.0.3 PHP Doctrine Inflector is a small library that can perform string manipulations with regard to upper/lowercase and singular/plural forms of words.
doctrine/instantiator 1.4.0 A small, lightweight utility to instantiate objects in PHP without invoking their constructors
doctrine/lexer 1.2.1 PHP Doctrine Lexer parser library that can be used in Top-Down, Recursive Descent Parsers.
doctrine/migrations 3.2.1 PHP Doctrine Migrations project offer additional functionality on top of the database abstraction layer (DBAL) for versioning your database schema and easily deploying changes to it. It is a very easy to use and a powerful tool.
doctrine/orm 2.9.5 Object-Relational-Mapper for PHP
doctrine/persistence 2.2.2 The Doctrine Persistence project is a set of shared interfaces and functionality that the different Doctrine object mappers share.
doctrine/sql-formatter 1.1.1 a PHP SQL highlighting library
I just checked some projects I work on and I definitely still see the deprecation about the ExceptionConverterDriver interface. Unfortunately, the issue is not that easy to solve because we have to implement all interfaces to avoid failures with instanceof checks 😞
Still seing deprecations in 4.2.6 for DBAL 3.3.1
2022-02-02T18:39:03+00:00 [info] User Deprecated: Class "Sentry\SentryBundle\Tracing\Doctrine\DBAL\TracingDriverConnection" should implement method "Doctrine\DBAL\Driver\Connection::getNativeConnection(): resource|object".
2022-02-02T18:39:03+00:00 [info] User Deprecated: Class "Sentry\SentryBundle\Tracing\Doctrine\DBAL\TracingServerInfoAwareDriverConnection" should implement method "Doctrine\DBAL\Driver\Connection::getNativeConnection(): resource|object".
2022-02-02T18:39:03+00:00 [info] User Deprecated: The "Sentry\SentryBundle\Tracing\Doctrine\DBAL\TracingServerInfoAwareDriverConnection" class implements "Doctrine\DBAL\Driver\ServerInfoAwareConnection" that is deprecated The methods defined in this interface will be made part of the {@see Driver} interface in the next major release.
2022-02-02T18:39:03+00:00 [info] User Deprecated: Class "Sentry\SentryBundle\Tracing\Doctrine\DBAL\TracingServerInfoAwareDriverConnection" should implement method "Doctrine\DBAL\Driver\Connection::getNativeConnection(): resource|object".
hi ~ I also encounter the deprecation messages on the console. What I found out was that when I enabled Sentry as a logger DebugHandlersListener of SF was called after Sentry ErrorHandler was initialized. Therefore the following code
$handler = set_exception_handler('var_dump');
$this->earlyHandler = \is_array($handler) ? $handler[0] : null;
restore_exception_handler();
sees the Sentry ErrorHandler instead of the Symfony ErrorHandler, what then results in the Logger not properly being setup for the ErrorHandler (which is normally done in DebugHandlersListener ::configure), which then results in the default BufferingLogger to be used for the deprecation message which are outputted at the end.
As a fix for this I used Sentry logger using the old behaviour using monolog.type=service instead of sentry and the lazy loaded that services. This way DebugHandlersListener __constructor is caller before Sentry changes the error_handler.
monolog:
handlers:
sentry:
type: service
id: App\Sentry\MonologHandler
see: https://symfony.com/doc/current/service_container/lazy_services.html
App\Sentry\MonologHandler:
lazy: true
public: true
arguments:
$hub: '@Sentry\State\HubInterface'
$level: !php/const Monolog\Logger::ERROR
I hope this helps
This issue has gone three weeks without activity. In another week, I will close it.
But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!
"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
The deprecation warnings make it almost impossible to see real errors. Odd, since this is Sentry's entire reason for being.
No idea how to solve it, alas, so I'm just part of the chorus hoping it happens.
On Wed, Mar 16, 2022 at 8:07 PM github-actions[bot] < @.***> wrote:
This issue has gone three weeks without activity. In another week, I will close it.
But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!
"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀
— Reply to this email directly, view it on GitHub https://github.com/getsentry/sentry-symfony/issues/483#issuecomment-1069761826, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEXIQP4JIO2U2NEWIMO3ODVAJZUPANCNFSM43FXRKGA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you are subscribed to this thread.Message ID: @.***>
The deprecation warnings make it almost impossible to see real errors.
I don't think that this is a fair statement. Just one deprecation remains, which is the one related to the DBAL, and it would have been fixed already if it was so easy to do it. The reality is a bit different unfortunately: that class is deprecated, but we have to implement it because otherwise our decorator would break the applications that expect the connection to be an instance of ExceptionConverterDriver
To be fair, I think that Symfony makes it too hard to hide deprecation errors. And monolog is very confusing to someone who just wants to capture errors.
It's not just Sentry, of course, several older bundles are full of deprecation warnings. It's an oft-discussed issue.
On Wed, Mar 16, 2022 at 8:39 PM Stefano Arlandini @.***> wrote:
The deprecation warnings make it almost impossible to see real errors.
I don't think that this is a fair statement. Just one deprecation remains, which is the one related to the DBAL, and it would have been fixed already if it was so easy to do it. The reality is a bit different unfortunately: that class is deprecated, but we have to implement it because otherwise our decorator would break the applications that expect the connection to be an instance of ExceptionConverterDriver
— Reply to this email directly, view it on GitHub https://github.com/getsentry/sentry-symfony/issues/483#issuecomment-1069780814, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEXIQILZ5ECNZ3VUOTOA63VAJ5NJANCNFSM43FXRKGA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you are subscribed to this thread.Message ID: @.***>
For me, it's not just the deprecations (from #596) but my app effectively and suddenly (with Sentry v3.4?) stopped working.
Please open a separate issue and post more details. An image of an error message is not enough to understand what's happening
Hey!
Facing same issue with deprecation error. Muting it in phpunit config does not work, using SYMFONY_DEPRECATIONS_HELPER=weak works fine, but that would result with any other deprecation slipping in our codebase and that's not wanted.
Can we fix this error? Some check on what version is used and determining correct class?
php -c [./php/conf.d/php.ini](https://bitbucket.org/usertech/fllite-be/src/02000d2c15d4d34752e214ed372108c260809179/php/conf.d/php.ini) vendor/bin/phpunit --configuration [./phpunit.xml](https://bitbucket.org/usertech/fllite-be/src/02000d2c15d4d34752e214ed372108c260809179/phpunit.xml) --testsuite unit
PHPUnit 9.5.20 #StandWithUkraine
Testing
.............................. 30 / 30 (100%)
Time: 00:00.032, Memory: 14.07 MB
OK (30 tests, 66 assertions)
Remaining indirect deprecation notices (2)
2x: The "Sentry\SentryBundle\Tracing\Doctrine\DBAL\TracingDriverForV3" class implements "Doctrine\DBAL\VersionAwarePlatformDriver" that is deprecated All drivers will have to be aware of the server version in the next major release.
2x in AirportCodeNormalizerTest::testNormalizeCustom from App\Tests\unit\Application\Airport
make: *** [test-unit] Error 1
Running following versions:
"doctrine/annotations": "^1.0",
"doctrine/doctrine-bundle": "^2.5",
"doctrine/doctrine-fixtures-bundle": "^3.4",
"doctrine/doctrine-migrations-bundle": "^3.2",
"doctrine/orm": "^2.11"
"sentry/sentry-symfony": "^4.2",
... symfony packages 5.4.* ...
Edit: Related to #579
@ste93cry can we drop the support for dbal v2 already and fix the deprecation? No need to support old dbal that is unmaintained. People can still install old versions of this lib to work with old dbal if needed.
I would love to, but I don't think it's feasible without the proof that the majority of people upgraded from DBAL 2.x. When we're talking about the userbase to support, the Sentry team is unwilling to leave a sizable chunk of users behind in most if not all of the cases, no matter the reason. @cleptric is now to the go-to person for this kind of decisions through
Looking at https://packagist.org/packages/doctrine/dbal/stats#major/all, I do see a 50/50 split between v2 and v3. So I don't see us of removing dbal v2 support anytime soon.
