I've created a mail notification that works successfully, but when trying to queue it, I get the following error:
Uncaught Exception: Serialization of 'Closure' is not allowed in /vendor/laravel/framework/src/Illuminate/Queue/Queue.php:125
Below is my code that I believe is causing the error:
public function toMail($notifiable)
{
$view_file = 'emails.verifyEmail';
$view = View::make($view_file, ['invitationToken' => $this->invitationToken, 'team_name' => $this->team->name, 'team_domain' => $this->team->domain ]);
$view = new HtmlString(with(new CssToInlineStyles)->convert($view));
return (new MailMessage)
->subject('Email Verification')
->view('emails.htmlBlank', ['bodyContent' => $view]);
}
I am not exactly sure where the 'Closure' it's trying to serialize is coming from. I tried tacking on ->render() to the end of View::make but that did not seem to make a difference. I believe it may have something to do with the view function of the MailMessage but I'm not really sure.
Once again, this notification works perfectly when it is not being Queued.
Any help would be appreciated.
Even if the question is pretty old, i'm posting this for future reference.
The problem occurs when the Queue tries to serialize the notification instance. This is done by serializing every property of the notification object. I had the same problem because i was doing something like
public function __construct(\Exception $ex){
$this->exception = $exception;
}
in my notification class.
Once the notification is wrapped in SendQueuedNotification it will be serialized by the Queue handler. During this process every property of SendQueuedNotification will be serialized, including our custom notification instance and its properties. Everything will fail when the serializer will try to serialize $exception instance; for some reason the exception class is unserializable because it probably contains a closure within its properties. So what worked for me was changing the constructor as follows
public function __construct(\Exception $ex)
{
$this->exceptionClass = get_class($ex);
$this->exceptionMessage = $ex->getMessage();
$this->exceptionLine = $ex->getFile() . '#' . $ex->getLine();
$this->exceptionCode = $ex->getCode();
}
Now all of the notification properties are fully serializable and everything works as expected.
Another solution is to use __wakeup() and __sleep() methods to customize the serialization and deserialization of your notification instance.
Hope it helps to understand your issue.
Related
I am calling afterSave method in application.php to perform action on all models saving event. Issue is whenever I using SAVE method inside afterSave method application showing fatal error:
SQLSTATE[HY000]: General error: 2006 MySQL server has gone away
Point is same method working fine in specific model, without any memory exhausted error, I think there is something that need to be fixed over database connection. Below is the code which one I am trying.
//Application.php file
namespace App;
...
...
\Cake\Event\EventManager::instance()->on(
'Model.afterSave',
function (
\Cake\Event\EventInterface $event,
\Cake\Datasource\EntityInterface $entity,
\ArrayObject $options
) {
$auth_data = isset($_SESSION['Auth'])?$_SESSION['Auth']:[];
$ActionLogs = TableRegistry::get('ActionLogs');
$ActionLogsEntity = $ActionLogs->newEmptyEntity();
$ActionLogsEntity->change_log = $change_log;
$ActionLogsEntity->action_taken_by = $auth_data->username;
$ActionLogs->save($ActionLogsEntity); //This statement working fine in specific modelTable
class Application extends BaseApplication
implements AuthenticationServiceProviderInterface
{
...
...
}
Aside from the fact that the code should go into the Application class' bootstrap() method as mentioned in the comments, when you save inside of an afterSave event that listens to all models, then you naturally create a recursion, as saving the log will trigger an afterSave event too.
You have to put a safeguard in place that prevents the logging logic from running when the afterSave event belongs to the logging model, for example:
if ($event->getSubject() instanceof \App\Model\Table\ActionLogsTable) {
return;
}
// ...
Edited:
I have a custom exception with render method which is being called when I throw it e.g. from controller, but not being called when I throw it in View composer.
So when I do something like that
public function compose(View $view)
{
throw new CustomException();
}
and put dd() to exception render method
public function render()
{
dd('render is called');
}
I get no result.
If I log my exception directly, finds out that first the CustomException being thrown, then as the result I see ErrorException.
I found a place where it being thrown.
\Illuminate\View\Engines\CompilerEngine::handleViewException
protected function handleViewException(Exception $e, $obLevel)
{
$e = new ErrorException($this->getMessage($e), 0, 1, $e->getFile(), $e->getLine(), $e);
parent::handleViewException($e, $obLevel);
}
I didn't found any mentions in Laravel docs about that case.
I found a tread on github with the same issue: https://github.com/laravel/framework/issues/24658
So the question is, is this expected? Is there any adequate way to avoid this behaviour?
Edit
So, as you know, any exception during view compilation is intercepted and rethrown as ErrorException or as FatalThrowableError.
What you can do is intercept ErrorException and check if ($e->getPrevious() instanceof \CustomException) if so, you do your code, else, let the handler continue.
So I've found working solution for myself.
I've extended CompilerEngine and added additional processing in order to not throw ErrorException when I don't want to.
The important thing is - your resulting Exception must be inherited from ErrorException. Otherwise you will face multiple calls to \App\View\Engines\CompilerEngine::handleViewException which can break your logic and write multiple log entities to your log file.
I have a unit test with the following:
use \Illuminate\Notifications\DatabaseNotification;
public function testMailSentAndLogged()
{
Notification::fake();
$user = factory(User::class)->create();
$emailAddress = $user->emailAddress;
$emailAddress->notify(new UserCreated);
Notification::assertSentTo(
$emailAddress,
UserCreated::class
);
error_log('DatabaseNotification '.print_r(DatabaseNotification::get()->toArray(), 1));
$this->assertEquals(1, $emailAddress->notifications->count());
}
My Notification has this for the via():
public final function via($notifiable)
{
// complex logic...
error_log('mail, database');
return ['mail', 'database'];
}
The code fails on the $this->assertEquals code. the error_log produces the following:
[03-Jan-2018 01:23:01 UTC] mail, database
[03-Jan-2018 01:23:01 UTC] DatabaseNotification Array
(
)
WHY don't the $emailAddress->notifications pull up anything? Why doesn't DatabaseNotification::get() pull anything?;
In your test, you are calling the method
Notification::fake();
As stated in Laravel's documentation on Mocking,
You may use the Notification facade's fake method to prevent
notifications from being sent.
Actually, this bit of code is the assertion that the Notification would have been sent, under normal circumstances (ie in prod) :
Notification::assertSentTo();
If you remove the call to Notification::fake(), your notification should appear in your testing database.
So you kinda have two solutions. The first one is to remove the call to fake(), thus really sending the notification, which will appear in the database. the second is not to test if the notification was written successfully in the database : it's Laravel's responsibility, not your application's. I recommand the second solution :)
I created a notification that I am passing a model to:
class NewMessage extends Notification implements ShouldQueue
{
use Queueable;
protected $message;
public function __construct(Message $message)
{
$this->message = $message;
}
public function via()
{
return ['database'];
}
public function toArray()
{
Log::info($this->message);
return [
'message_id' => $this->message->id,
];
}
}
And this is how I call the notification:
$message = Message::where('user_id', Auth::user()->id)
->where('message_id', $message_id)
->with('topic')
->get();
$user->notify(new NewMessage($message));
The problem is that when the notification prints the log (Log::info($this->message);), the topic relationship doesn't show up.
However, I found that if I change the toArray() function in the nofitication class to this, it prints out fine:
public function toArray()
{
$this->message->topic;
Log::info($this->message);
return [
'message_id' => $this->message->id,
];
}
Why? How do I fix this?
Note: this question/answer is only relevant for Laravel < 5.6. Starting in Laravel 5.6, loaded relationships are also serialized, so the issue in this question is no longer an issue.
Your notification is set to queue, and the Notification class you're extending uses the SerializesModels trait. When an object with the SerializesModels trait is serialized to be put on the queue, any Models contained on that object (e.g. your message) are replaced with just the id of that model (the message id). When the queue worker unserializes your notification to process it, it will use that message id to re-retrieve the message from the database. Unfortunately, when this happens, no relationships are included.
So, even though your message had the topic relationship loaded when it was serialized, it will not have the topic relationship loaded when the queue worker processes the notification. If you need the topic inside of your notification, you will need to reload it, as you have seen.
You can read more about this in the documentation here. The relevant part is quoted below:
In this example, note that we were able to pass an Eloquent model directly into the queued job's constructor. Because of the SerializesModels trait that the job is using, Eloquent models will be gracefully serialized and unserialized when the job is processing. If your queued job accepts an Eloquent model in its constructor, only the identifier for the model will be serialized onto the queue. When the job is actually handled, the queue system will automatically re-retrieve the full model instance from the database. It's all totally transparent to your application and prevents issues that can arise from serializing full Eloquent model instances.
I've got a Controller.php whose show($id) method is hit by a route.
public function show($id)
{
// fetch a couple attributes from the request ...
$this->checkEverythingIsOk($attributes);
// ... return the requested resource.
return $response;
}
Now, in checkEverythingIsOk(), I perform some validation and authorization stuff. These checks are common to several routes within the same controller, so I'd like to extract these checks and call the method everytime I need to perform the same operations.
The problem is, I'm unable to send some responses from this method:
private function checkEverythingIsOk($attributes)
{
if (checkSomething()) {
return response()->json('Something went wrong'); // this does not work - it will return, but the response won't be sent.
}
// more checks...
return response()->callAResponseMacro('Something else went wrong'); // does not work either.
dd($attributes); // this works.
abort(422); // this works too.
}
Note: Yes, I know in general one can use middleware or validation services to perform the checks before the request hits the controller, but I don't want to. I need to do it this way.
As of Laravel 5.6 you can now use for example response()->json([1])->send();.
There is no need for it to be the return value of a controller method.
Note that calling send() will not terminate the output. You may want to call exit; manually after send().
You are probably looking for this:
function checkEverythingIsOk() {
if (checkSomething()) {
return Response::json('Something went wrong');
}
if(checkSomethingElse()) {
return Response::someMacro('Something else is wrong')
}
return null; // all is fine
}
And in the controller method:
$response = $this->checkEverythingIsOk();
if($response !== null) { // $response instanceof Response
return $response;
}
It's probably overkill, but I will throw it in anyway. You might want to look into internal requests. Also this is just pseudoish code, I have not actually done this, so take this bit of information with caution.
// build a new request
$returnEarly = Request::create('/returnearly');
// dispatch the new request
app()->handle($newRequest);
// have a route set up to catch those
Route::get('/returnearly', ...);
Now you can have a Controller sitting at the end of that route and interpret the parameters, or you use multiple routes answered by multiple Controllers/Methods ... up to you, but the approach stays the same.
UPDATE
Ok I just tried that myself, creating a new request and dispatching that, it works this way. Problem is, the execution does not stop after the child-request has exited. It goes on in the parent request. Which makes this whole approach kind of useless.
But I was thinking about another way, why not throw an Exception and catch it in an appropriate place to return a specified response?
Turns out, thats already built into Laravel:
// create intended Response
$response = Response::create(''); // or use the response() helper
// throw it, it is a Illuminate\Http\Exception\HttpResponseException
$response->throwResponse();
Now usually an Exception would be logged and you if you are in Debug mode, you would see it on screen etc. etc. But if you take a look into \Illuminate\Foundation\Exceptions\Handler within the render method you can see that it inspects the thrown Exception if it is an instance of HttpResponseException. If it is then the Response will be returned immediately.
To me the most simple and elegant way is:
response()->json($messages_array, $status_code)->throwResponse();
(you don`t need return)
It can be called from a private function or another class...
I use this in a helper class to check for permissions, and if the user doesn`t have it I throw with the above code.