通知电子邮件序列化错误与 ShouldQueue 缺少请求对象错误

Notification eMail Serialization Error vs Missing Request Object Error with ShouldQueue

我有一个 Laravel 通知 class 可以向一组收件人发送电子邮件。在没有 ShouldQueue 的情况下,使用我传递给 Notification class:

$request 对象可以完美地工作
class MassNotification extends Notification {
     public function __construct($request)
     {
        $this->request = $request;
     }

这来自 控制器 像这样:

\Notification::send($emps, new MassNotification($request));

我需要将这些电子邮件排队,以便让用户继续前进,所以我实现了 ShouldQueue:

class MassNotification extends Notification implements ShouldQueue {}

此时,消息失败并出现以下错误:

Serialization of 'Closure' is not allowed

稍微 , 告诉我这是因为无法序列化 $request 对象。好的,我按照建议更改构造函数以拉入我需要的数据数组:

public function __construct($request)
 {
    $this->request = $request->all();
 }

我更改了 toMail() 中的代码以满足数组表示法与对象表示法,并且每次 在到达 toMail() 方法之前它都失败了 与:

Call to a member function has() on null at /vagrant/app/Notifications/MassNotification.php:44

但是,这指向我的代码 - 但我的代码中不再有 has(),它永远不会到达那一行 - 我相信它在 Illuminate\Notifications\Channels\MailChannel->send() 中失败了。

我试图完全取出请求数组并仅使用变量(例如 $this->message$this->subject 等),但 Notification 似乎正在寻找要使用的对象 has() 每一次。

我猜我遗漏了一些非常基本的东西,因为它不能同时被破坏。我将不胜感激。

如果您 运行 遇到这样一种情况,您的代码更新似乎没有到位并且您的错误与当前代码不匹配并且您正在使用排队的作业,那么工作人员需要重新启动。队列工作者 运行 处于守护进程模式,并将应用程序的启动状态保存在内存中。他们不会看到您对代码所做的更改。

"Remember, queue workers are long-lived processes and store the booted application state in memory. As a result, they will not notice changes in your code base after they have been started. So, during your deployment process, be sure to restart your queue workers." - Laravel 6.x Docs - Queues - Running The Queue Worker