Consent to the use of Personal Data and Cookies

This website needs your consent to use cookies in order to customize ads and content.

If you give us your consent, data may be shared with Google.

AclPermissionCollection not found during decoding

When updating Shopware, AclPermissionCollection may no longer exist, resulting in a clogged enqueue table and breaking the message workers.

10 views
d

By. Jacob

Edited: 2022-05-23 12:01

Error thrown while running command "messenger:consume". Message: "Message class "Shopware\Core\Framework\Api\Acl\Permission\AclPermissionCollection" not found during decoding." {"exception":"[object] (Symfony\Component\Messenger\Exception\MessageDecodingFailedException(code: 0): Message class "Shopware\Core\Framework\Api\Acl\Permission\AclPermissionCollection" not found during decoding. at /var/www/shopware/vendor/symfony/messenger/Transport/Serialization/PhpSerializer.php:90)","command":"messenger:consume","message":"Message class "Shopware\Core\Framework\Api\Acl\Permission\AclPermissionCollection" not found during decoding."} []

I had to deal with this strange error message in a recently updated Shopware installation, and this one was very difficult to track down. Basically there is nothing in the error logs indicating what may have been the cause, and the error message itself is not very informative; the message just tells us that the AclPermissionCollection class is apparently missing, but not much as to indicate which specific component that is trying to call the missing class.

Reading the error, it looks like something is trying to use a permission component used to be located inside vendor/shopware/core/Framework/Api/Acl/ – however, no such folder seem to exist in later versions of Shopware.

So what did I do to track down the calling code?

When something like this happens, one of the easiest ways to track down the code that is calling the class is, simply, to use the grep command in Linux on the root folder of the application. E.g.:

grep -r "AclPermissionCollection" /var/www/shopware

Unfortunately, in this case at least, doing this gives us no results, and it also could take a very long time depending on the size of your Shopware site. In fact, it is usually better to try and narrow it down; presumably, if something was indeed calling this code, it would be more likely to be located inside a plugin than Shopware itself, and so this may be more useful:

grep -r "AclPermissionCollection" /var/www/shopware/custom

Still no results. But, I also tried doing this on the parent folder, which also kept the .sql backups of the site; interestingly, I found occurrences of AclPermissionCollection in our database backups.

The problem appears to be some sort of message being stuck in the Symfony enqueue database table and preventing us from running bin/console messenger:consome; now, as far as I know, this table just holds tasks (or messages) to be consumed by a worker, meaning that something put it there, perhaps from an earlier Shopware version, and to fix the problem I simply removed the tasks referencing the AclPermissionCollection class. E.g.:

echo 'DELETE FROM shopware.enqueue WHERE body LIKE "%AclpermissionCollection%"' | mysql -ushopware -p;

Doing this will remove the clogged tasks from the enqueue table.

Here is the exception trace on the error:

Exception trace:
 at /var/www/shopware/vendor/symfony/messenger/Transport/Serialization/PhpSerializer.php:90
 Symfony\Component\Messenger\Transport\Serialization\PhpSerializer::handleUnserializeCallback() at n/a:n/a
 unserialize() at /var/www/shopware/vendor/symfony/messenger/Transport/Serialization/PhpSerializer.php:76
 Symfony\Component\Messenger\Transport\Serialization\PhpSerializer->safelyUnserialize() at /var/www/shopware/vendor/symfony/messenger/Transport/Serialization/PhpSerializer.php:38
 Symfony\Component\Messenger\Transport\Serialization\PhpSerializer->decode() at /var/www/shopware/vendor/sroze/messenger-enqueue-transport/QueueInteropTransport.php:86
 Enqueue\MessengerAdapter\QueueInteropTransport->get() at /var/www/shopware/vendor/symfony/messenger/Worker.php:102
 Symfony\Component\Messenger\Worker->run() at /var/www/shopware/vendor/symfony/messenger/Command/ConsumeMessagesCommand.php:225
 Symfony\Component\Messenger\Command\ConsumeMessagesCommand->execute() at /var/www/shopware/vendor/symfony/console/Command/Command.php:298
 Symfony\Component\Console\Command\Command->run() at /var/www/shopware/vendor/symfony/console/Application.php:1033
 Symfony\Component\Console\Application->doRunCommand() at /var/www/shopware/vendor/symfony/framework-bundle/Console/Application.php:96
 Symfony\Bundle\FrameworkBundle\Console\Application->doRunCommand() at /var/www/shopware/vendor/symfony/console/Application.php:299
 Symfony\Component\Console\Application->doRun() at /var/www/shopware/vendor/symfony/framework-bundle/Console/Application.php:82
 Symfony\Bundle\FrameworkBundle\Console\Application->doRun() at /var/www/shopware/vendor/symfony/console/Application.php:171
 Symfony\Component\Console\Application->run() at /var/www/shopware/bin/console:74

Tell us what you think:

  1. How to debug a problem in Shopware where getLabel() returns null instead of string.
  2. Things that might go wrong with Scheduled Tasks in Shopware.
  3. How to fix an error in Shopware that prevents displaying the frontpage: Unable to find a matching sales channel

More in: Shopware