{"id":553821,"date":"2026-08-18T09:42:36","date_gmt":"2026-08-18T09:42:36","guid":{"rendered":"https:\/\/webkul.com\/blog\/?p=553821"},"modified":"2026-08-18T09:42:42","modified_gmt":"2026-08-18T09:42:42","slug":"pimcore-messenger-worker","status":"publish","type":"post","link":"https:\/\/webkul.com\/blog\/pimcore-messenger-worker\/","title":{"rendered":"Pimcore Messenger Worker: Fix a Stuck Job Queue"},"content":{"rendered":"

You dispatch an import, an export, or a translation job in Pimcore. The job screen shows it as queued<\/strong> or started<\/strong>. Then nothing happens. The progress bar never moves, and the queue just grows.<\/p>\n

This is the classic Pimcore Messenger Worker<\/strong> problem. The job sits in the queue, but no worker drains it. This guide walks through every common cause and its fix, in the order you should check them.<\/p>\n

Everything here is grounded in a real Pimcore 12 (Platform 2026.1) install and its Symfony Messenger setup. So the commands and transport names are the actual ones you will use.<\/p>\n

\"pimcore-messenger-worker-stuck-queue\"<\/p>\n

What a Stuck Queue Actually Means<\/h2>\n

Pimcore runs long jobs off the web request with Symfony Messenger<\/a><\/strong>. A controller drops a small message onto a transport. Then a long-running worker process picks it up and runs the job to completion.<\/p>\n

That worker is a single command:<\/p>\n

bin\/console messenger:consume <transport> --memory-limit=250M --time-limit=3600<\/pre>\n
So a “stuck queue” almost always means one thing. The message is on the transport, but no healthy Pimcore Messenger Worker is consuming it. Your job stays started<\/strong> because nothing moved it forward.<\/p>\n
The Messenger queue tracks delivery, not job progress. Pimcore keeps a separate tracking table for status and counts. So a frozen progress bar points at the worker, not your data.<\/p><\/blockquote>\n
First, Check the Pimcore Messenger Worker Is Running<\/h2>\n
Start with the obvious. Is a worker alive for that queue at all?<\/p>\n
On Docker, the workers run under Supervisor. So check them there:<\/p>\n
supervisorctl status<\/pre>\n
You want the messenger programs showing RUNNING<\/strong>, not FATAL<\/strong> or EXITED<\/strong>. On a stock Pimcore container, one program consumes the core transports:<\/p>\n
messenger:consume pimcore_generic_data_index_queue scheduler_generic_data_index pimcore_core pimcore_maintenance pimcore_scheduled_tasks pimcore_image_optimize pimcore_asset_update pimcore_generic_execution_engine<\/pre>\n
Connector bundles add their own programs too. For example, a DeepL<\/a> or BigCommerce<\/a> install appends its own consumer for the deepl<\/code>, bigcommerce_import<\/code>, or bigcommerce_export<\/code> queue.<\/p>\n
No process manager? Then start a worker by hand and watch it live:<\/p>\n
bin\/console messenger:consume pimcore_core -vv<\/pre>\n
Cause 1: No Worker for That Specific Queue<\/h2>\n
This is the most common cause by far. A worker runs, but not for your<\/em> queue.<\/p>\n
Each connector uses its own transport. So a running core worker does nothing for a bigcommerce_export<\/code> message. First, see where the backlog sits:<\/p>\n
SELECT COUNT(*), queue_name FROM messenger_messages GROUP BY queue_name;<\/pre>\n
If rows pile up under a queue with no matching consumer, that is your answer. Add or restart the consumer for that exact transport. On Docker, that means a Supervisor program that names the queue.<\/p>\n
Cause 2: The Transport Fell Back to sync:\/\/<\/h2>\n
Sometimes the job runs inline<\/em> instead of queuing. As a result, the dispatch call blocks, and the browser hangs until the whole job finishes.<\/p>\n
This happens when a transport resolves to sync:\/\/<\/code>. Many dev .env<\/code> files override the Messenger DSN prefix to sync:\/\/<\/code> to skip a real broker. So every “async” job then runs on the web request.<\/p>\n
Confirm the routing your message actually got:<\/p>\n
bin\/console debug:config framework messenger.routing<\/pre>\n
Your message class should list senders: [your_queue]<\/code>. However, if it shows sync<\/code> or the wrong transport, the routing is off. Clear the cache and check again:<\/p>\n
bin\/console cache:clear<\/pre>\n
Cause 3: A kill -9 Ghost Is Blocking the Queue<\/h2>\n
Never kill -9<\/code> a worker while a job runs. It kills the process mid-message and leaves two problems behind.<\/p>\n