Sentry\Context\OsContext::__construct(): Argument #1 ($name) must be of type string, null given, called in /home/vol14_4/infinityfree.com/if0_36374154/htdocs/laravel/vendor/sentry/sentry/src/Integration/EnvironmentIntegration.php on line 58
I’m sorry, but what do you expect us to do for you?
The error message is pretty clear: the parameter given is of an invalid type. Looking at the code paths, it seems that you’re using Laravel and Sentry. And apparently, something is wrong with that, either in your configuration, your integration code, or the different versions of Laravel, Sentry and Sentry-Laravel you are using.
But if you expect that you can just dump an error message in here and we’ll debug your code for you. If you can’t be bothered to describe the issue, please try solving the issue with Google or ChatGPT or something first.
Hi prathamdagar2,
You can try composer update on your local development environment and replace the vendor folder hosted on the server to see if that resolves.
Since you cannot run commands on the server using SSH, you might want to clear cached blade views by clearing folders under for:
storage/framework/cachestorage/framework/sessionsstorage/framework/viewsThis action is equivalent to running php artisan optimize:clear
Let us know if this solves your case or additional assistance is required.
Cheers!
By looking at the OP’s website, I believe the fail may be caused by Sentry’s integration
(Sentry\Integration\EnvironmentIntegration:58, second vendor frame from the top), in the method updateServerOsContext, where the constructor is called with php_uname as a parameter:
if (null === $osContext) {
$osContext = new OsContext(php_uname('s'));
}
php_uname had been reported as being a disabled function some time ago, but something must have changed, as Sentry’s implementation also contains a check in lines 53-55 that seems to be bypassed:
if (!\function_exists('php_uname')) {
return $osContext;
}
Was php_uname modified to return nothing? My own testing with a var_dump seems to yield those results (it prints NULL).
If this is the case, would polyfilling the function to return a generic/anonymized Linux system information be possible, and of help?
Great find @ChrisPAR! I’ll check with iFastNet if the php_uname stub can be tweaked so it won’t break Sentry. The function is always supposed to return a string (if it’s available), but the stub does not.
The issue should now be fixed! The php_uname function now no longer returns null, but returns real looking values instead (so you’ll have some usable information in Sentry too).
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.