framework: Queueing email fails with PHP 7.3: Class setQueue does not exist
- 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.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 1
- Comments: 75 (48 by maintainers)
I have filed a bug report here: https://bugs.php.net/bug.php?id=77310
I’ve released 5.7.18 with this “work-around” to use
$this->app
which resolves the bug on my machine. However, hopefully the PHP team will still look at this as I’m worried it could affect other areas of code too.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.
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
database
and not using Redis at all.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 just experienced this as well, and I too use the PHP Redis extension, not predis, so I suspect that’s where the issue is.
Attention anyone seeking answers to this riddle:
You need PHP 7.3.1.
@vimalmistry try upgrading to PHP 7.3 and Laravel to the latest version, it should be solved by now.
Now that @fridzema mentioned telescope, I remember that when I got that error where I ended syncing my files with the
laravel/laravel
repo, one other thing I did was to remove telescope.I got the error in projects with telescope installed but not in projects without it.
Currently all my forge servers and projects in production (4 servers and 5 projects) are upgraded to PHP 7.3 with opcache enabled and I am not having these errors anymore. I also use the php-redis extension instead of predis.
If it is of any help, Taylor or someone from Laravel Forge team can look at my forge setup. But there is nothing fancy in any of them.
@hotmeteor i can’t say with confidence yes or no, but for me removing telescope was the fix at the moment. Maybe there happened some opcache busting what it actually solved. Didn’t investigate further at the time.
Just read Taylor’s bug report on this issue here https://bugs.php.net/bug.php?id=77310 and ended up downgrading php to 7.2.13 until next Laravel’s release.
fwiw, I was getting a “Class setEventDispatcher does not exist” on Homebrew PHP 7.3. I disabled OPCache and ran
valet restart
. Everything is now working as expected.Its a PHP 7.3 and OPCache problem… I solved it downgrading to PHP 7.2 and disabling OPCache (I have read that only disablig OPCache works too)
@rodrigopedra My
bootstrap/app.php
is completely up-to-date with thelaravel/laravel
project. I always watch the changes to that repo and keep them in sync.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
$app
variable when we are actually attempting to callsetQueue
on the$mailer
variable.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.