Repository navigation
Queueing email fails with PHP 7.3: Class setQueue does not exist #26819
Description
- Laravel Version: 5.7.17
- PHP Version: 7.3
- Database Driver & Version: MySQL 5.7
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:
Mail::to($user->email)->send(new FooMail($user));where Mail is Illuminate\Support\Facades\Mail
the class FooMail:
use Illuminate\Bus\Queueable;
use Illuminate\Mail\Mailable;
use Illuminate\Queue\SerializesModels;
use Illuminate\Contracts\Queue\ShouldQueue;
class FooMail extends Mailable implements ShouldQueue
{
use Queueable, SerializesModels;
public function build() {
return $this->view('emails.foo')->subject(...)->replyTo(...)->with([...]);
}
}My config:
MAIL_DRIVER=smtp
MAIL_HOST=email_host
MAIL_PORT=25
MAIL_USERNAME=username
MAIL_PASSWORD=secret
MAIL_ENCRYPTION=tls
MAIL_FROM_NAME='Foo Bar'
CACHE_DRIVER=redis
QUEUE_CONNECTION=redis
SESSION_DRIVER=redis
REDIS_HOST=redis-master
REDIS_PASSWORD=null
REDIS_PORT=6379
REDIS_QUEUE=default
Furthermore I'm using phpredis as the client, not predis.
When I send an email I get the following error:
[2018-12-12 19:05:17] local.ERROR: Class setQueue does not exist {"exception":"[object] (ReflectionException(code: -1): Class setQueue does not exist at /Users/thom/Sites/fooProject/vendor/laravel/framework/src/Illuminate/Container/Container.php:779)
[stacktrace]
#0 /Users/thom/Sites/fooProject/vendor/laravel/framework/src/Illuminate/Container/Container.php(779): ReflectionClass->__construct('setQueue')
#1 /Users/thom/Sites/fooProject/vendor/laravel/framework/src/Illuminate/Container/Container.php(658): Illuminate\\Container\\Container->build('setQueue')
#2 /Users/thom/Sites/fooProject/vendor/laravel/framework/src/Illuminate/Container/Container.php(609): Illuminate\\Container\\Container->resolve('setQueue', Array)
#3 /Users/thom/Sites/fooProject/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(733): Illuminate\\Container\\Container->make('setQueue', Array)
#4 /Users/thom/Sites/fooProject/vendor/laravel/framework/src/Illuminate/Container/Container.php(1222): Illuminate\\Foundation\\Application->make('setQueue')
#5 /Users/thom/Sites/fooProject/vendor/laravel/framework/src/Illuminate/Mail/MailServiceProvider.php(52): Illuminate\\Container\\Container->offsetGet('setQueue')
#6 /Users/thom/Sites/fooProject/vendor/laravel/framework/src/Illuminate/Container/Container.php(776): Illuminate\\Mail\\MailServiceProvider->Illuminate\\Mail\\{closure}(Object(Illuminate\\Foundation\\Application), Array)
#7 /Users/thom/Sites/fooProject/vendor/laravel/framework/src/Illuminate/Container/Container.php(658): Illuminate\\Container\\Container->build(Object(Closure))
#8 /Users/thom/Sites/fooProject/vendor/laravel/framework/src/Illuminate/Container/Container.php(609): Illuminate\\Container\\Container->resolve('mailer', Array)
#9 /Users/thom/Sites/fooProject/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(733): Illuminate\\Container\\Container->make('mailer', Array)
#10 /Users/thom/Sites/fooProject/vendor/laravel/framework/src/Illuminate/Container/Container.php(1222): Illuminate\\Foundation\\Application->make('mailer')
#11 /Users/thom/Sites/fooProject/vendor/laravel/framework/src/Illuminate/Support/Facades/Facade.php(161): Illuminate\\Container\\Container->offsetGet('mailer')
#12 /Users/thom/Sites/fooProject/vendor/laravel/framework/src/Illuminate/Support/Facades/Facade.php(130): Illuminate\\Support\\Facades\\Facade::resolveFacadeInstance('mailer')
#13 /Users/thom/Sites/fooProject/vendor/laravel/framework/src/Illuminate/Support/Facades/Facade.php(217): Illuminate\\Support\\Facades\\Facade::getFacadeRoot()
#14 /Users/thom/Sites/fooProject/app/Observers/FooObserver.php(189): Illuminate\\Support\\Facades\\Facade::__callStatic('to', Array)
#15 /Users/thom/Sites/fooProject/app/Observers/FooObserver.php(132): App\\Observers\\CommentObserver->sendFooEmails(Object(App\\Foo), Object(Illuminate\\Database\\Eloquent\\Collection))
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.
Activity
driesvints commentedon Dec 13, 2018
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.
ThomHurks commentedon Dec 13, 2018
@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?
driesvints commentedon Dec 13, 2018
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.
chris-hud commentedon Dec 13, 2018
I'm getting the same issue.
Expected behavior in vagrant box running PHP 7.2.5-1. Works in dev server running 7.2. I am migrating to production in a newly created forge server running 7.3 and it fails. To further confuse matters, It worked last night for a time period of 5 minutes when I invited initial users. I cannot get it to work today.
See: https://stackoverflow.com/questions/53002885/laravel-5-7-class-setqueue-does-not-exist
devcircus commentedon Dec 13, 2018
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.
chris-hud commentedon Dec 13, 2018
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.*",
chris-hud commentedon Dec 13, 2018
Error on:
Mail::to($user->email)->send(new InviteUser($user));Mail Class:
.env
StackTrace
reinink commentedon Dec 15, 2018
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.
hotmeteor commentedon Dec 16, 2018
Same here. I think @reinink is onto it.
Jam0r85 commentedon Dec 16, 2018
Using predis here and same issue.
Oddly enough it goes away when I use ShouldQueue.
eg. the following works
class NewRentalStatement extends Notification implements ShouldQueuehowever, the following does not.
class NewRentalStatement extends NotificationProving troublesome as I cannot send password reset links in Nova or Wink.
Jam0r85 commentedon Dec 16, 2018
Quick and dirty, commenting out the following in the MailServiceProvider solves the issue.
if ($app->bound('queue')) { $mailer->setQueue($app['queue']); }taylorotwell commentedon Dec 17, 2018
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
$mailerinstance in MailServiceProvider can ever be a container instance, which is what the bug seems to imply.Also adding an interface to the class fixing it makes no sense either.
52 remaining items
besthman commentedon Jan 10, 2019
How did you update to 7.3.1? Are you using Linux, Ubuntu?
I am assuming that you're using mac..?
victordevsquad commentedon Jan 17, 2019
If using macOs, upgrade php to 7.3.1, by simply running
brew upgrade php.vicgonvt commentedon Jan 24, 2019
Confirmed, 7.3.1 fixes this issue.
ThomHurks commentedon Jan 25, 2019
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
GrahamCampbell commentedon Jan 25, 2019
@ThomHurks Please see the pinned issue: #27052.
vicgonvt commentedon Jan 25, 2019
@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.
ThomHurks commentedon Jan 25, 2019
@GrahamCampbell Hadn't seen that one yet. Thanks!
@vicgonvt What version of Laravel are you running?
vicgonvt commentedon Jan 25, 2019
@ThomHurks Laravel Framework 5.7.22
ThomHurks commentedon Jan 25, 2019
@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.
vicgonvt commentedon Jan 25, 2019
@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.
ThomHurks commentedon Jan 25, 2019
@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.
vicgonvt commentedon Jan 25, 2019
@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.
ThomHurks commentedon Jan 25, 2019
@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.
driesvints commentedon Jan 28, 2019
Please wait with upgrading if you need this until PHP 7.3.2 has been released.