-
Notifications
You must be signed in to change notification settings - Fork 11k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Queueing email fails with PHP 7.3: Class setQueue does not exist #26819
Comments
Can you please check #26136 and try some of the things suggested there? Restarting Horizon, PHP-FPM, nginx, queues, etc. If nothing helps feel free to report back. |
@driesvints We're running the application and the workers in Kubernetes with Docker containers, so restarting PHP/nginx is not applicable, as we built new images and started those. We're also not using Horizon. I literally only change the base image to PHP 7.2 and redeploy and it works again, so I think you can reopen this? |
Okay. I'll try to look at this at a later time. I can't seem to figure it out at moment. It's pretty bizare what's going on here. |
I'm getting the same issue. See: https://stackoverflow.com/questions/53002885/laravel-5-7-class-setqueue-does-not-exist |
There's several results from Google for this same issue where the user had issues with 7.3 only but was able to resolve. Seemed to be a config setting in those examples. |
I have seen those google results where the issue was using QUEUE_DRIVER instead of QUEUE_CONNECTION in env and config. I have QUEUE_CONNECTION set correctly. laravel/framework: "5.7.*", |
Error on: Mail Class:
.env
StackTrace
|
I just experienced this as well, and I too use the PHP Redis extension, not predis, so I suspect that's where the issue is. |
Same here. I think @reinink is onto it. |
Using predis here and same issue. Oddly enough it goes away when I use ShouldQueue. eg. the following works
however, the following does not.
Proving troublesome as I cannot send password reset links in Nova or Wink. |
Quick and dirty, commenting out the following in the MailServiceProvider solves the issue.
|
This error seems really weird. It makes me wonder how could it even be a Laravel bug at all rather than something PHP related. There is no way the Also adding an interface to the class fixing it makes no sense either. |
I am unable to recreate this with Predis. It will take me a bit longer before I can try it with the Redis PHP extension. |
I'd have to dive deeper into the code later today, but at quick glance there is a comment that says // Once we have create the mailer instance, we will set a container instance
// on the mailer. This allows us to resolve mailer classes via containers
// for maximum testability on said classes instead of passing Closures. Not sure if that's related. |
I was able to recreate it a few times with the |
Update: I am able to recreate it when I restart PHP-FPM... I can recreate it several times before it goes away again. I'm basically 100% certain this is not a Laravel bug but is some kind of PHP related bug that occurs when the Redis extension is installed. |
What's everyone's OS here? macOS? Which Linux distro? |
Heroku, Heroku-16 stack (Ubuntu 16.04) |
@taylorotwell Definitely possible it's a PHP bug, as that's the changing variable. What are the next steps then, report it to the PHP project? Haven't dealt with that process myself. @driesvints I got the bug both on my dev machine (MacOS Mojave) using Valet and on the Docker containers running in Kubernetes (base image Debian Stretch, underlying machines run a Linux distro but I forget which one) |
MacOS 10.14.1 Everything installed through Brew and upgraded, etc. |
It's a PHP bug of some kind. I can literally add blank lines to the MailServiceProvider and make the bug resolve and mails delivery successfully. There is nothing we can do on our end. It will need to be reported to the PHP team itself. I can make it happen even when my queue driver is set to |
Disabling Opcache entirely also removes the error. In summary, it seems like when Opcache is enabled on PHP 7.3, it tries to use the |
I have filed a bug report here: https://bugs.php.net/bug.php?id=77310 |
I got this when i had installed the beta of telescope, removing it fixed it for me. |
Another way to fix the bug is if we do not use the |
I've released 5.7.18 with this "work-around" to use |
Gonna leave this open for the time being to follow up. |
In my case it was not about php version, but code: I had:
and the method payToUser:
When I removed the code after creating transaction It just worked. By the way, in my local environment (win7+ php7.2.2) never was the error but only using dokku with php 7.3 |
In my case it was not about php version, but code: I had:
and the method payToUser:
When I removed the code after creating transaction It just worked. By the way, in my local environment (win7+ php7.2.2) never was the error but only using dokku with php 7.3 |
I think it sounds like this is working with 7.3.1RC1. It's odd that 7.3.1 wasn't released today. I guess it's behind schedule due to new year? |
Yes, indeed, the fix is listed in the release notes for the upcoming PHP 7.3.1 release: https://github.com/php/php-src/blob/PHP-7.3.1/NEWS#L39. |
I'm having the same issue with laravel 5.6 and php 7.3 with OPCache how did you disable it I tried many method without any success I did edit |
@3alampro Please read the thread a little more closely before commenting (others should do this as well, that would be awesome). TL;DR:
|
FYI: 7.3.1 was just released. |
I am experiencing the same issue. I am using PHP7.3 on Ubuntu 16.04. |
Attention anyone seeking answers to this riddle: You need PHP 7.3.1. |
I saw it, it was released today, right? Is there any other way to install the latest PHP for Ubuntu? Any help is appreciated |
wait a day or two |
Downgraded to php 7.2.13 since I have less time to wait. But will try to upgrade to php7.3.1 when it's released and keep you guys updated. Thx for the help |
Updating to 7.3.1 solved the issue for me. |
How did you update to 7.3.1? Are you using Linux, Ubuntu? |
If using macOs, upgrade php to 7.3.1, by simply running |
Confirmed, 7.3.1 fixes this issue. |
Have the people who claim that "7.3.1 fixes it" actually tested with the older version of Laravel? The last few releases include a workaround for this bug, so naturally that will work regardless of the PHP version. The reason I'm asking is because PHP itself claims this bug will only be resolved in version 7.3.2 |
@ThomHurks Please see the pinned issue: #27052. |
@ThomHurks I have a production environment running PHP 7.2.10 and the same code base in local development, and yes, I can confirm that 7.3.0 broke the same codebase locally. Upon upgrading my local to 7.3.1, my test suite is back to green. |
@GrahamCampbell Hadn't seen that one yet. Thanks! |
@ThomHurks Laravel Framework 5.7.22 |
@vicgonvt That's what I thought, and what I pointed out in my previous comment; that version of Laravel has a workaround for this bug, so you wouldn't be affected by it even if PHP 7.3.1 still had this bug. It should be officially fixed in PHP 7.3.2, according to the bug report Taylor filed on php.net. Some (other) OPCache bugs were fixed in 7.3.1 though. |
@ThomHurks AHA!, didn't get that the first round of messages. So I guess the workaround is only valid for 7.3.1, because I was getting errors running 7.3.0. |
@vicgonvt The workaround should be valid for 7.3.0 too, but be aware that 7.3.0 had a lot more issues than just this bug. I've decided for my own projects to wait a few patch releases before I attempt another go at PHP 7.3 for this reason. |
@ThomHurks I was unable to get passed that setQueue error just yesterday on 7.3.0 and still on 5.7.22. There is definitely something going on there with that. But you are right, we are keeping our production environment locked to 7.2.*. I mostly upgraded my local environment to play with the new PHP features, not really intending to deploy that change to production. |
@vicgonvt Ouch, that sounds like the workaround that was added to Laravel doesn't actually work around the problem then. I'll see if I can do some testing tomorrow with my own setup. |
Please wait with upgrading if you need this until PHP 7.3.2 has been released. |
Description:
When using Laravel with PHP 7.3, you get an error when queueing emails. I'm using a Redis queue for this. With PHP 7.2 everything works fine.
Steps To Reproduce:
I get an error on the line:
where
Mail
isIlluminate\Support\Facades\Mail
the class
FooMail
:My config:
Furthermore I'm using phpredis as the client, not predis.
When I send an email I get the following error:
When I use PHP 7.2 instead of PHP 7.3 then, without changing anything else, it works fine and it sends the email without errors.
The text was updated successfully, but these errors were encountered: