sentry-laravel: Uncaught Error: Class 'Raven_Client' not found
I recenty got this error after upgrading our composer. Did the original Sentry package got updated where the Raven_Client got deprecated or so?
PHP Fatal error: Uncaught Error: Class 'Raven_Client' not found in /api/vendor/sentry/sentry-laravel/src/Sentry/SentryLaravel/SentryLaravel.php:18 Stack trace: #0 /api/vendor/sentry/sentry-laravel/src/Sentry/SentryLaravel/SentryLaravelServiceProvider.php(101): Sentry\SentryLaravel\SentryLaravel::getClient(Array) #1 /api/vendor/laravel/framework/src/Illuminate/Container/Container.php(776): Sentry\SentryLaravel\SentryLaravelServiceProvider->Sentry\SentryLaravel\{closure}(Object(Illuminate\Foundation\Application), Array) #2 /api/vendor/laravel/framework/src/Illuminate/Container/Container.php(658): Illuminate\Container\Container->build(Object(Closure)) #3 /api/vendor/laravel/framework/src/Illuminate/Container/Container.php(609): Illuminate\Container\Container->resolve('sentry', Array) #4 /api/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(759): Illuminate\Container\Container->make('sentry', Array) #5 /api/vendor/sentry/sentry-laravel/src/Sentry/SentryLaravel/SentryLaravel.php on line 18
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 7
- Comments: 18 (2 by maintainers)
@stayallive , you must be kidding us. What you did (to break an official version that has been stable for almost 3 years) is against any versioning management best practice. Furthermore, your breaking change was against the official Composer guideline. I really don’t get how come your change has passed through a revision process.
To what guidelines are you referring to? Composer tries to follow Semantic versioning, and basically all Composer constraints use that spec (or subset of it). Furthermore, they even recently joined the SemVer team: https://github.com/semver/semver/issues/495.
If you read through the SemVer spec, point 8 says that any kind of breakage is allowed (only) between major versions, and point 4 says that any 0.x version is to be considered unstable, and API changes are to be expected.
This was a major version increase, and furthermore starting from an unstable one.
Lastly, I invite you to be more kind toward the maintainer, which is devoting his free time to work on this package.
Probably why you are having trouble going back is because you are trying to go back to
1.0.0which is actually the new version we just released (which has the breaking change).If you go back to
0.11.0you should be all set and back to how it was before 👍The breaking change is happening on the bump from
0.11.0to1.0.0(which is perfectly acceptable from a SemVer point of view).We figured out why this is happening and where we wen’t wrong, so here is the solution for downgrading problems.
Because of incorrect version constraints on
sentry/sentry-laravelversion0.8and lower it allows forsentry/sentryversion2.0to be installed (which has the breaking changes) butsentry-laravelbelow version1.0is not compatible.The constraint on version
0.8of the Laravel integration was to requiresentry/sentry:>=1.7.0this also includes2.0(visualized), in0.9we switched to the correct constraint ofsentry/sentry:^1.9.0(visualized).So to fix install
sentry/sentry-laravelof at least version0.9, but better ofcourse being the latest0.11release which correctly only installs1.xof the PHP SDK.So if you are still on
0.8of the Laravel integration and or trying to downgrade to0.8(or lower) you will still install the2.0of the PHP SDK.We will work on getting hotfixes out for the older versions fixing the constraints!
The version in composer.json was “^0.8.0”. However, for some reason, when updating, sentry/sentry got updated from 1.7 to 2.0. What’s more, “composer update” is executed daily, only yesterday the changes were introduced for some reason, without us changing anything into our composer configurations. I was really puzzled, the only explanation is that there are some dependency issues.
It took me approximately 8 hours of debugging the sentry/sentry package to realize that the events were sent but were not received because of the lack of valid SSL certificate. In version 0.8 such a thing was not necessary, so this is a hidden dependency when upgrading from 0.8.0 to 1.0 I understand that breaking changes are inevitable, but from a user perspective you need an upgrade guideline. Take Laravel for example: https://laravel.com/docs/5.8/upgrade
For you guys having problems with Sentry going from
0.8.0directly to1.0.0, go back to0.11.0as mentioned by @stayallive.We have multiple deployments daily and when we reverted back to
0.8.0(as we had before the issue) we still got the exception above. Why we never got upgraded to0.11.0in the first place still amazes me… Probably due to how we initially set up Sentry, following the Official Sentry Documentation for Laravel.I agree with @mdzhokanov, my apps just broke. I undestand that it’s a breaking change but it’s not easy to go back. I’m trying to go bck to 1.0.0 version and still not working. Again, I understand that it is a breaking change; but, a breaking change should not be so difficult to rollback.
I had the same error, bumped the version to 1.0 as per the documentation. I changed the configuration file and everything seems to be OK. However, the captureException method does not report to Sentry. "php artisan sentry:test"successfully generates an event, but I cannot verify anywhere that it has been received. Any ideas why?