Since I upgraded from Magento 2.2.7 to Magento 2.3.1 I am getting this message in the system.log file:

main.INFO: Consumer "async.operations.all" skipped as required connection "amqp" is not configured. Unknown connection name amqp [] []

I get this error also on a fresh Magento 2.3.1 install.

Where could I configure or disable it?

  • 1
    i too have this issue. did you get this sorted out?
    – Zoya
    Apr 13 '19 at 1:05
  • 1
    no not yet. not much info on this problem
    – RaFr
    Apr 14 '19 at 13:09
  • 1
    Thank you. Please let me know if you find something.
    – Zoya
    Apr 14 '19 at 16:18
  • 1
    same issue here...magento 2.3.1 with php7.2
    – styzzz
    Apr 18 '19 at 0:34
  • I too have this issue in magento 2.3.3. did you get this sorted out? Jan 23 '20 at 9:52

The answer from @Rafael Corrêa Gomes (and any to the point that mentions either 'cron_run' => false or 'consumers' => ['async.operations.all'] in the configuration are quite outrageous because they make many folks copy-paste and destroy their message queues from functioning.

cron_run set to false in configuration means that the message consumers are not going to be launched by the Magento cron. It means that you will have to run them using other means like SupervisorD or SystemD. And if not (and those answers don't mention that at all), you will have broken stuff beyond words "message queues", which includes, at very minimum, data export in Magento admin.

The documentation that is being referred to when posting such configuration has incorrect heading below this section with words:

Specific configuration

instead of

Sample configuration

It is a sample, and not a standard. Neither it is a recommendation to solve anything.

But, while the docs are at fault, it doesn't excuse skipping the lines and not reading further, then posting destructive solutions online.

The real solution is either disabling the Bulk API which most installations don't use, essentially:

php bin/magento module:disable Magento_WebapiAsync

Or, configure RabbitMQ if you want the bulk API (highly unlikely, depends on specific use case).

  • I always disable the Magento_Amqp too as I have the idea (perhaps an illusion!) that third party modules might decide to use it, but in its absence can revert to other operation mode. Is it unnecessary to disable it?
    – iphigenie
    May 31 '20 at 9:00
  • From the looks of it, Magento_Amqp will act as a "driver" for Magento_WebapiAsync. So by disabling Magento_Amqp you're indirectly disabling Magento_WebapiAsync as well. For "in its absence can revert to other operation mode" - no, I don't think that's a safe assumption. If we take the Magento_WebapiAsync for example, it absolutely wants/needs AMQP/RabbitMQ set up, and cannot function in other operation modes. So the same thing can be assumed for any modules that will rely on Magento_Amqp. As in - they will not function when it's disabled. May 31 '20 at 10:14
  • Strangely, when only one is disabled I stil get error messages in some scenarios. Disabling Amqp removes the async.operations.all consumer, disabling WebapiAsync removes a user of the async.operations.all, which from your explanation I understand to be the only one. But I see other modules with async in my tree, who could one day try to use it next update, hence why i worry.
    – iphigenie
    May 31 '20 at 12:00

Danila is above is right Solutions that tell you to do cron_run = 'false" will disable other queues you do want, like bulk attribute update or export file generation.

Option 1 disable packages

php bin/magento module:disable Magento_WebapiAsync
php bin/magento module:disable Magento_Amqp

I think it makes sense to disable both as the absence of Ampq allows modules to switch to mysql - but I haven't dug deep into that. Indeed if all you want is for the error message to vanish then Danilo's option is all you need

Option 2 Tweak your queue cron, dont disable it

This is if you don't want to or can't take core modules off.

  1. List your existing queues

    bin/magento queue:consumers:list

  2. Add all of them except async to your cron consumer, in env.php. If there is functionality you never use, skip that one (but remember you did...)

'queue' => [
    'consumers_wait_for_messages' => 0,
'cron_consumers_runner' => [
    'cron_run' => true,
    'max_messages' => 2,
    'single_thread' => true,
    'consumers-wait-for-messages' => 0,
    'consumers' => [

Most places have a higher max_messages but if you are not having rabbitmq you are possibly on a low budget host too and short queues more often are better. Up the number as you want.

Option 3 - take things out of internal cron and add them manually, queue per queue, to cron

this implies

cron_run => false

and then putting things like bin/magento queue:consumers:start --single-thread --max-messages=20 inventory.source.items.cleanup in your cron (or running them manually if you do it rarely. If you have a shared server 'consumers_wait_for_messages' => 0 or consumers-wait-for-messages=1 is key for memory management

  • updated for new management parameters
    – iphigenie
    Sep 11 '20 at 13:33
  • *consumers_wait_for_messages Mar 25 at 20:14
  • you're right @NickRolando in the config file it is consumers_wait_for_messages as a command parameter it is consumers-wait-for-messages
    – iphigenie
    Mar 30 at 9:14
  • @iphigenie so that's a typo in the env.php example?
    – Typo
    Aug 2 at 18:56

Edit the /app/etc/env.php file to configure the cron job consumers_runner.

return [

// ...

    'cron_consumers_runner' => [
        'cron_run' => true,
        'max_messages' => 20000,
        'consumers' => [

]; // return closing

To get the list of all your queue consumers that can be configured running:

php bin/magento queue:consumers:list

Reference: https://devdocs.magento.com/guides/v2.4/config-guide/mq/manage-message-queues.html#configuration

  • how is this a solution? you're disabling the async queues
    – Alex Bejan
    Nov 25 '19 at 16:48
  • 1
    Hi @AlexBejan, there are two answers, it's enabled by default so disabling is just an option when you don't pretend to use it, you if you want you can use the configuration that I recommended, it's the same as Magento DevDocs recommends. Nov 26 '19 at 16:32
  • I'm not sure what the addition to the env.php does here. If I want to enable async sending of messages, do I add that code or do I edit the cron_run to be true?
    – Webninja
    Dec 7 '19 at 21:23
  • Left the cron_run false @Webninja Dec 7 '19 at 22:42
  • 1
    Yes, that I noticed. So if that is left to false Magento does not send emails by cron? Or what is the effect of that setting?
    – Webninja
    Dec 8 '19 at 9:00

I ran into this on Magento 2.3.1 and after some searching through the docs I found this link: https://devdocs.magento.com/guides/v2.3/config-guide/mq/manage-message-queues.html

Here it explains what it does and it says you can edit the /app/etc/env.php file to configure the cron job consumers_runner. I decided to add this "async.operations.all" consumer here.


I went with this at the end of app/etc/env.php

'cron_consumers_runner' => array(
        'cron_run' => false,
        'max_messages' => 20000,
        'consumers' => array(
  • 1
    only set cron_run to false if you have setup your own consumer cron process, it will disable the consumer_runner cron task that initiates the consumers.
    – paj
    Feb 12 at 10:15

Short answer: Create config file in your custom module {module_vendor}/{module_name}/etc/queue_consumer.xml with following content:

<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    <consumer name="async.operations.all" connection="db"/>

Detailed answer: Magento has default implementation for message queue based on MySQL - Magento_MysqlMq. All default Magento modules, which requires message queue processing, uses this MySQL implementation (example: vendor/magento/module-inventory-catalog/etc/queue_consumer.xml) by connection="db" for their consumers. But for some reason Magento_WebapiAsync expects RabbitMQ implementation which is available by default in Magento Commerce (maybe this module was developer for Magento Commerce).

So solution is to move this consumer from RabbitMQ (which is unavailable) to MySQL-MQ (which is available by default)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.