Hi Sentry! I updated via Composer yesterday from 2.4.0 to 2.4.1 and my entire dev site went down. Logs are below, but it looks like an issue of argument type inheritance upstream from Guzzle? Regardless I'm surprised a minor point upgrade like this would cause a failure with no other implementation changes so I thought I would report it.
Workaround for now is to leave the SDK definition "sentry/sdk": "2.0.3" but specify the older framework: "sentry/sentry": "2.4.0". At some point I would like to update though so a fix or explanation would be greeted warmly.
PHP: 7.2.31 (shared hosting 馃槶)
OS: Ubuntu 18.04
Server: Apache
PHP Fatal error: Uncaught TypeError: Argument 1 passed to Http\Client\Curl\Client::__construct() must be an instance of Psr\Http\Message\ResponseFactoryInterface or null, instance of Http\Message\MessageFactory\GuzzleMessageFactory given, called in /var/www/project/vendor/sentry/sentry/src/HttpClient/HttpClientFactory.php on line 139 and defined in /var/www/project/vendor/php-http/curl-client/src/Client.php:79
Stack trace:
#0 /var/www/project/vendor/sentry/sentry/src/HttpClient/HttpClientFactory.php(139): Http\Client\Curl\Client->__construct(Object(Http\Message\MessageFactory\GuzzleMessageFactory), Object(Http\Message\StreamFactory\GuzzleStreamFactory), Array)
#1 /var/www/project/vendor/sentry/sentry/src/Transport/DefaultTransportFactory.php(58): Sentry\HttpClient\HttpClientFactory->create(Object(Sentry\Options))
#2 /var/www/project/vendor/sentry/sentry/src/ClientBuilder.php(307): Se in /var/www/project/vendor/php-http/curl-client/src/Client.php on line 79
Would you mind sharing your composer.json and the code you use to initialize the SDK if it's different from relying on Sentry\init()?
Sure. I shared the relevant parts of composer.json above. The project is not open source but here's the redacted version in JSON format:
{
"name": "project/project",
"type": "project",
"description": "Project",
"minimum-stability": "dev",
"prefer-stable": true,
"require": {
"php": ">=7.2",
"twbs/bootstrap": "^4.3",
"components/jquery": "^3.3",
"enyo/dropzone": "^5.5",
"fortawesome/font-awesome": "^5.8",
"bower-asset/sbadmin2": "^4.0",
"datatables/datatables": "^1.10",
"nnnick/chartjs": "^2.8",
"peekleon/datatables-all": "^1.10",
"eternicode/bootstrap-datepicker": "^1.9",
"sentry/sdk": "2.0.3",
"bower-asset/bootstrap-datepicker-eternicode": "^1.9",
"bower-asset/featherlight": "^1.7"
},
"require-dev": {
"mikey179/vfsstream": "1.6.*",
"phpunit/phpunit": "^8.5"
},
"autoload-dev": {
"psr-4": {
"Tests\\Support\\": "tests/_support"
}
},
"scripts": {
"test": "phpunit",
"post-update-cmd": [
"@composer dump-autoload",
]
}
}
That's the version with the error. Adding "sentry/sentry": "2.4.0", fixes it. I am using Sentry\init() but here's the code from the boot file if that helps:
<?php
/*
|--------------------------------------------------------------------------
| ERROR DISPLAY
|--------------------------------------------------------------------------
| Don't show ANY in production environments. Instead, let the system catch
| it and display a generic error message.
*/
ini_set('display_errors', 0);
error_reporting(E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_STRICT & ~E_USER_NOTICE & ~E_USER_DEPRECATED);
/*
|--------------------------------------------------------------------------
| DEBUG MODE
|--------------------------------------------------------------------------
| Debug mode is an experimental flag that can allow changes throughout
| the system. It's not widely used currently, and may not survive
| release of the framework.
*/
defined('CI_DEBUG') || define('CI_DEBUG', 0);
/*
*---------------------------------------------------------------
* SENTRY.IO
*---------------------------------------------------------------
* Initialize Sentry for exception reporting.
*/
Sentry\init(['dsn' => 'https://{redacted}@sentry.io/{redacted}' ]);
From the error message it seems that some package (could it be something required by some package not mentioned in the composer.json?) is trying to install php-http/curl-client, The HTTPlug autodiscovery seems to find the cURL HTTP client and the Guzzle PSR-17 factory which are not compatible together. I'm not sure about why this happens, but one solution you could try to workaround the issue is to manually initialize the SDK using the client builder and specifying the PSR factories manually
It's your package my man. Here's the log from the breaking upgrade last night:
[project]# composer install
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Package operations: 1 install, 9 updates, 0 removals
- Updating composer/composer (1.10.7 => 1.10.8): Loading from cache
- Updating psr/http-client (1.0.0 => 1.0.1): Loading from cache
- Updating php-http/discovery (1.8.0 => 1.9.0): Loading from cache
- Updating php-http/client-common (2.1.0 => 2.2.0): Loading from cache
- Updating sentry/sentry (2.4.0 => 2.4.1): Loading from cache
- Updating myclabs/deep-copy (1.9.5 => 1.10.1): Loading from cache
- Updating phpdocumentor/reflection-common (2.1.0 => 2.2.0): Loading from cache
- Updating phpdocumentor/type-resolver (1.2.0 => 1.3.0): Loading from cache
- Installing bower-asset/featherlight (1.7.13): Loading from cache
- Updating codeigniter4/codeigniter4 dev-develop (f66f324 => dbdafec): Checking out dbdafec23e
... and my subsequent inspection:
[project]# composer show sentry/sdk
name : sentry/sdk
descrip. : This is a metapackage shipping sentry/sentry with a recommended http client.
keywords :
versions : * 2.0.3
type : metapackage
license : MIT License (MIT) (OSI approved) https://spdx.org/licenses/MIT.html#licenseText
homepage :
source : [git] https://github.com/getsentry/sentry-php-sdk.git 91c36aec83e4c1c5801b64ef4927b78a5aa8ce7f
dist : [zip] https://api.github.com/repos/getsentry/sentry-php-sdk/zipball/91c36aec83e4c1c5801b64ef4927b78a5aa8ce7f 91c36aec83e4c1c5801b64ef4927b78a5aa8ce7f
path : /home/hatteras/public_html/ci4.boats4sale.com
names : sentry/sdk
requires
http-interop/http-factory-guzzle ^1.0
php-http/curl-client ^1.0|^2.0
sentry/sentry ^2.0.1
Notice that last part in particular, "requires php-http/curl-client ^1.0|^2.0".
My guess at this point is if I upgrade the Sentry SDK to sentry/sdk: ^2.1 then whatever underlying disjoint will be fixed, but since Sentry docs (https://docs.sentry.io/platforms/php/#integrating-the-sdk) direct people to install a specific version (e.g. composer require sentry/sdk:2.0.3, when I installed) rather than the semantically-safe versioning (e.g. ^2.0) your clients will often be running older versions when using Composer for package management. So if this issue was caused by some upstream dependency disjoint I think that is something worth figuring out.
Definitely still open to fact that I screwed something up, but a breaking minor point update and fixing rollback are suspicious.
since Sentry docs (https://docs.sentry.io/platforms/php/#integrating-the-sdk) direct people to install a specific version (e.g. composer require sentry/sdk:2.0.3, when I installed) rather than the semantically-safe versioning (e.g. ^2.0) your clients will often be running older versions when using Composer for package management
You're absolutely right, we need to update the documentation accordingly and I'm sure @HazAT will be more than happy to do it
It's your package my man
My bad, I didn't notice that you were using a fixed version of sentry/sdk. Indeed updating to the latest version of this package will solve the issue (hopefully)
So if this issue was caused by some upstream dependency disjoint I think that is something worth figuring out.
As I said, it looks like php-http/discovery is discovering Guzzle (non-PSR) factories along with the cURL HTTP client which expects instead PSR factories and thus the error is thrown. I'm not sure though why you only get this error after the latest patch release, we didn't change anything that could affect this so probably the issue is in the upstream package. I will try to take a look at it and report back any findings
Awesome! Thanks for digging. I will update to 2.1.0 and report back.
we need to update the documentation accordingly
Safe to assume then that you recommend using the semantically-safe latest version of sentry/sdk? If so I will make the switch now which should also handle the above.
Safe to assume then that you recommend using the semantically-safe latest version of
sentry/sdk?
Absolutely yes. I think we should also evaluate whether it makes sense to somehow syncronize the releases of both sentry/sdk and sentry/sentry or to restrict the required version of the latter to prevent such issues in the future
Documentation has been fixed in getsentry/sentry-docs#1848. I checked and we don't need to specify a version requirement in the composer require command as Composer will automatically pin to ^x.x
Good news on the docs! I will check it out shortly.
we don't need to specify a version requirement
That's correct, Composer will default to a semantically-safe requirement on the latest available compatible version.
Confirmed that sentry/sdk 2.1.0 resolves this issue, as suspected. I will leave this issue open until you all are done with it, but my problems are all behind me 馃檭
Closing as this should be resolved in the mentioned PR. Release will follow shortly!
Most helpful comment
Confirmed that
sentry/sdk 2.1.0resolves this issue, as suspected. I will leave this issue open until you all are done with it, but my problems are all behind me 馃檭