I have a laravel event with a few listeners. Some listeners or their notifications (depending if they are time consuming) are implementing the ShouldQueue
so they run in the background on a redis
queue. The event uses SerializesModels
by default, but when one of the passed models to the event is the logged in user and we fire it, like this:
$user = $this->user(); // logged in user instance
event(new UserCreatedPost($user, $post, $modelX, $modelY));
I am not able to access the user's followers in the respective listener, to check whether or not to notify them if they exist:
// In listener handle method
public function handle(UserCreatedPost $event){
$followers = $event->user->followers()->get();
}
I get this error:
Call to undefined method Illuminate\Contracts\Database\ModelIdentifier::followers()
The only way I was able to get it to work was to add event wakeup below:
public function handle(UserCreatedPost $event){
// This fixes it, as it unserializes all the models
// (even though we only need this model to be unserialized, not all of them)
$event->__wakeup();
$followers = $event->user->followers()->first();
// If at least one follower exists send queued notification
// else exit
}
I do use the $user
instance in a few other listeners under the same event and other event listeners. I don't even know if the $user
should be serialized in the first place at all, but it is a model, so the parent event SerializesModels
trait automatically serializes all the models (and I don't know of any way to make this specific model not be serialized while other models yes).
Is there a better way to be able to access the $user
in the listeners without having to do the wakeup
call at all? I have many events with listeners, and just got to implementing queues now, so I really don't want to add that wakeup
to all areas in all files that the error would appear, but I do want to queue some of the listeners or their notifications. An alternative would be to remove the event SerializesModels
trait and not even worry about that error showing up under this or any other listener I have yet to discover this error in. Are there any issues that can arise, like performance for example or others, by implementing the alternative approach? Any better way?