Flag of Ukraine
SymfonyCasts stands united with the people of Ukraine
TRACK

Symfony 5 >

COURSE

Messenger! Queue work for Later

Buy Access to Course

Passing Entity Ids inside of Messages

English Español

Keep on Learning!

If you liked what you've learned so far, dive in!
Subscribe to get access to this tutorial plus
video, code and script downloads.

Start your All-Access Pass
Buy just this tutorial for $12.00
Previous Chapter

Next Chapter
Edit on GitHub

With a Subscription, click any sentence in the script to jump to that part of the video!

Login Subscribe

Suppose you need your friend to come over and watch your dog for the weekend - let's call her Molly. So you write them a message explaining all the details they need to know: how often to feed Molly, when to walk her, exactly where she likes to be scratched behind the ears, your favorite superhero movie and the name of your childhood best friend. Wait... those last two things... while fascinating... have nothing to do with watching your dog Molly!

And this touches on a best-practice for designing your message classes: make them contain all the details the handler needs... and nothing extra. This isn't an absolute rule... it just makes them leaner, smaller and more directed.

Passing the Entity Id

If you think about our message, we don't really need the entire ImagePost object. The smallest thing that we could pass is actually the id... which we could then use to query for the ImagePost object and get the filename.

Change the constructor argument to int $imagePostId. I'll change that below and go to Code -> Refactor to rename the property. Oh, and brilliant! It also renamed my getter to getImagePostId(). Update the return type to be an int. We can remove the old use statement as extra credit.

21 lines src/Message/AddPonkaToImage.php
... lines 1 - 2
namespace App\Message;
use App\Entity\ImagePost;
class AddPonkaToImage
{
private $imagePostId;
public function __construct(int $imagePostId)
{
$this->imagePostId = $imagePostId;
}
public function getImagePostId(): int
{
return $this->imagePostId;
}
}

Next, in ImagePostController, search for AddPonkaToImage and... change this to $imagePost->getId().

95 lines src/Controller/ImagePostController.php
... lines 1 - 21
class ImagePostController extends AbstractController
{
... lines 24 - 38
public function create(Request $request, ValidatorInterface $validator, PhotoFileManager $photoManager, EntityManagerInterface $entityManager, MessageBusInterface $messageBus)
{
... lines 41 - 60
$message = new AddPonkaToImage($imagePost->getId());
... lines 62 - 64
}
... lines 66 - 93
}

Our message class is now as small as it can get. Of course, this means that we have a little bit extra work to do in our handler. First, the $imagePost variable is not... well.. an ImagePost anymore! Rename it to $imagePostId.

40 lines src/MessageHandler/AddPonkaToImageHandler.php
... lines 1 - 11
class AddPonkaToImageHandler implements MessageHandlerInterface
{
... lines 14 - 26
public function __invoke(AddPonkaToImage $addPonkaToImage)
{
$imagePostId = $addPonkaToImage->getImagePostId();
... lines 30 - 37
}
}

To query for the actual object, add a new constructor argument: ImagePostRepository $imagePostRepository. I'll hit Alt + Enter -> Initialize Fields to create that property and set it.

40 lines src/MessageHandler/AddPonkaToImageHandler.php
... lines 1 - 7
use App\Repository\ImagePostRepository;
... lines 9 - 11
class AddPonkaToImageHandler implements MessageHandlerInterface
{
... lines 14 - 16
private $imagePostRepository;
... line 18
public function __construct(PhotoPonkaficator $ponkaficator, PhotoFileManager $photoManager, EntityManagerInterface $entityManager, ImagePostRepository $imagePostRepository)
{
... lines 21 - 23
$this->imagePostRepository = $imagePostRepository;
}
... lines 26 - 38
}

Back in the method, we can say $imagePost = $this->imagePostRepository->find($imagePostId).

40 lines src/MessageHandler/AddPonkaToImageHandler.php
... lines 1 - 11
class AddPonkaToImageHandler implements MessageHandlerInterface
{
... lines 14 - 26
public function __invoke(AddPonkaToImage $addPonkaToImage)
{
... line 29
$imagePost = $this->imagePostRepository->find($imagePostId);
... lines 31 - 37
}
}

That's it! And this fixes our Doctrine problem! Now that we're querying for the entity, when we call flush(), it will correctly save it with an UPDATE. We can remove the persist() call because it's not needed for updates.

Let's try it! Because we just changed code in our handler, hit Ctrl+C to stop our worker and then restart it:

php bin/console messenger:consume -vv

Here we go! Upload a new file... check the worker - yep, it processed just fine - and... refresh! Yes! No duplication, Ponka is visiting my workshop and the date is set!

Failing Gracefully

But... sorry to bring up bad news... what if the ImagePost can't be found for this $imagePostId? That shouldn't happen... but depending on your app, it might be possible! For us... it is! If a user uploads a photo, then deletes it before the worker can handle it, the ImagePost will be gone!

Is that really a problem? If the ImagePost was already deleted, do we care if this handler blows up? Probably not... as long as you've thought about how it will explode and are intentional.

Check this out: let's start by saying: if (!$imagePost) so we can do some special handling... instead of trying to call getFilename() on null down here. If this happens, we know that it's probably just because the image was already deleted. But... because I hate surprises on production, let's log a message so that we know this happened... just in case it's caused by a bug in our code.

Logger Injection with LoggerAwareInterface

Starting in Symfony 4.2, there's a little shortcut to getting the main logger service. First, make your service implement LoggerAwareInterface. Then, use a trait called LoggerAwareTrait.

55 lines src/MessageHandler/AddPonkaToImageHandler.php
... lines 1 - 9
use Psr\Log\LoggerAwareInterface;
use Psr\Log\LoggerAwareTrait;
... lines 12 - 13
class AddPonkaToImageHandler implements MessageHandlerInterface, LoggerAwareInterface
{
use LoggerAwareTrait;
... lines 17 - 30
public function __invoke(AddPonkaToImage $addPonkaToImage)
{
... lines 33 - 35
if (!$imagePost) {
... lines 37 - 44
}
... lines 46 - 52
}
}

That's it! Let's peek inside LoggerAwareTrait. Ok cool. In the core of Symfony, there's a little bit of code that says:

whenever you see a user's service that implements LoggerAwareInterface, automatically call setLogger() on it and pass the logger.

By combining the interface with this trait... we don't have to do anything! We instantly have a $logger property we can use.

How to Fail in your Handler

Ok, so back inside our if statement... what should we do if the ImagePost isn't found? We have two options... and the correct choice depends on the situation. First, we could throw an exception - any exception - and that would cause this message to be retried. More retries soon. Or, you could simply "return" and this message will "appear" to have been handled successfully... and will be removed from the queue.

Let's return: there's no point in retrying this message later... that ImagePost is gone!

55 lines src/MessageHandler/AddPonkaToImageHandler.php
... lines 1 - 13
class AddPonkaToImageHandler implements MessageHandlerInterface, LoggerAwareInterface
{
... lines 16 - 30
public function __invoke(AddPonkaToImage $addPonkaToImage)
{
... lines 33 - 35
if (!$imagePost) {
// could throw an exception... it would be retried
// or return and this message will be discarded
... lines 39 - 43
return;
}
... lines 46 - 52
}
}

But let's also log a message: if $this->logger, then $this->logger->alert() with, how about,

Image post %d was missing!

passing $imagePostId for the wildcard.

55 lines src/MessageHandler/AddPonkaToImageHandler.php
... lines 1 - 13
class AddPonkaToImageHandler implements MessageHandlerInterface, LoggerAwareInterface
{
... lines 16 - 30
public function __invoke(AddPonkaToImage $addPonkaToImage)
{
... lines 33 - 35
if (!$imagePost) {
// could throw an exception... it would be retried
// or return and this message will be discarded
if ($this->logger) {
$this->logger->alert(sprintf('Image post %d was missing!', $imagePostId));
}
return;
}
... lines 46 - 52
}
}

Oh, and the only reason I'm checking to see if $this->logger is set is... basically... to help with unit testing. Inside Symfony, the logger property will always be set. But on an object-oriented level, there's nothing that guarantees that someone will have called setLogger()... so this is just a bit more responsible.

Witnessing Errors in your Handler

Let's try this thang! Let's see what happens if we delete an ImagePost before it's processed! First, move over, stop the handler, and restart it:

php bin/console messenger:consume -vv

And because each message takes a few seconds to process, if we upload a bunch of photos... and delete them super quick... with any luck, we'll delete one before its message is handled.

Let's see if it worked! So... some did process successfully. But... yea! This one has an alert! And thanks to the "return" we added, it was "acknowledged"... meaning it was removed from the queue.

Oh... and interesting... there's another error I didn't plan for below:

An exception occurred while handling message AddPonkaToImage: File not found at path...

That's awesome! This is what it looks like if, for any reason, an exception is thrown in your handler. Apparently the ImagePost was found in the database... but by the time it tried to read the file on the filesystem, it had been deleted!

The really amazing part is that Messenger saw this failure and automatically retried the message a second... then a third time. We'll talk more about failures and retries a bit later.

But first, our DeleteImagePost message is still being handled synchronously. Could we make it async? Well... no! We need the ImagePost to be deleted from the database immediately so that the user doesn't see it if they refresh. Unless... we could split the delete task into two pieces... Let's try that next!

Leave a comment!

Most Useful Newest Oldest
5
Login or Register to join the conversation
Default user avatar
Default user avatar Cristóbal Rejdych | posted 3 years ago

Hi guys,
I wanna ask about LoggerAwareTrait. You wrote in this tutorial:


Oh, and the only reason I'm checking to see if $this->logger is set is... basically... to help with unit testing. Inside Symfony, the logger property will always be set. But on an object-oriented level, there's nothing that guarantees that someone will have called setLogger()... so this is just a bit more responsible.

But yesterday I did manual tests for some of my project functionality and I discovered that logger setted inside MessageHandler by using LoggerAwareTrait and implementing LoggerAwareInterface is always null. So I thought it's probably something wrong with logger. So I created new one by Dependency injection in constructor and that one works correctly. What could I do wrong with LoggerAwareTrait?? I use Symfony 4.3.11.

Reply
MolloKhan Avatar

Hey Cristóbal Rejdych

That's odd. I tested it on Symfony 4.4 and it worked fine. Can you double-check if you imported the right classes


use Psr\Log\LoggerAwareInterface;
use Psr\Log\LoggerAwareTrait;

if that's not the case, can you upgrade to Symfony 4.4? it's possible that there is a bug on the version you are

Cheers!

Reply
Default user avatar
Default user avatar Cristóbal Rejdych | MolloKhan | posted 3 years ago

Hi Diego,
yeah I'm imported that classes, implement LoggerAwareInterface and use LoggerAwareTrait inside class. So if nothing else could break it down, it must be bug. For now I change it to simple DI inside constructor, but when I complete all required by project tasks I try to upgrade it to Symfony 4.4 and wrote here result.

Thanks a lot for reply.
Cheers ;)!

Reply
MolloKhan Avatar

Interesting... One last thing I can think of is that you have to restart the Messenger Worker every time you change your App's code but I suppose you did that so I'm leaning towards a bug on Messenger

Reply
Default user avatar
Default user avatar Cristóbal Rejdych | MolloKhan | posted 3 years ago

Yeah I'm restarting worker after any changes I do inside messenger. Like I wrote before I was curious of this problem and I'm upgraded Symfony to latest version 4.4 and test it again and problem with this trait still exist, so it's not bug in Symfony, but fortunately DI logger service still work properly so I don't see reason to make it big problem which must be resolved. If I in the future find cause of problem I will post info about it here ;)

1 Reply
Cat in space

"Houston: no signs of life"
Start the conversation!

This tutorial is built with Symfony 4.3, but will work well on Symfony 4.4 or 5.
Symfony 4.3

What PHP libraries does this tutorial use?

// composer.json
{
    "require": {
        "php": "^7.1.3",
        "ext-ctype": "*",
        "ext-iconv": "*",
        "composer/package-versions-deprecated": "^1.11", // 1.11.99
        "doctrine/annotations": "^1.0", // v1.8.0
        "doctrine/doctrine-bundle": "^1.6.10", // 1.11.2
        "doctrine/doctrine-migrations-bundle": "^1.3|^2.0", // v2.0.0
        "doctrine/orm": "^2.5.11", // v2.6.3
        "intervention/image": "^2.4", // 2.4.2
        "league/flysystem-bundle": "^1.0", // 1.1.0
        "phpdocumentor/reflection-docblock": "^3.0|^4.0", // 4.3.1
        "sensio/framework-extra-bundle": "^5.3", // v5.3.1
        "symfony/console": "4.3.*", // v4.3.2
        "symfony/dotenv": "4.3.*", // v4.3.2
        "symfony/flex": "^1.9", // v1.18.7
        "symfony/framework-bundle": "4.3.*", // v4.3.2
        "symfony/messenger": "4.3.*", // v4.3.4
        "symfony/property-access": "4.3.*", // v4.3.2
        "symfony/property-info": "4.3.*", // v4.3.2
        "symfony/serializer": "4.3.*", // v4.3.2
        "symfony/validator": "4.3.*", // v4.3.2
        "symfony/webpack-encore-bundle": "^1.5", // v1.6.2
        "symfony/yaml": "4.3.*" // v4.3.2
    },
    "require-dev": {
        "easycorp/easy-log-handler": "^1.0.7", // v1.0.7
        "symfony/debug-bundle": "4.3.*", // v4.3.2
        "symfony/maker-bundle": "^1.0", // v1.12.0
        "symfony/monolog-bundle": "^3.0", // v3.4.0
        "symfony/stopwatch": "4.3.*", // v4.3.2
        "symfony/twig-bundle": "4.3.*", // v4.3.2
        "symfony/var-dumper": "4.3.*", // v4.3.2
        "symfony/web-profiler-bundle": "4.3.*" // v4.3.2
    }
}
Edit on GitHub
Previous Chapter
Next Chapter
userVoice