4

I've spent a few hours trying to figure this out however I haven't progressed much so I thought I'd post here. I'm having issues with the Bulk Actions not starting, the task gets queued however that's all it does, it doesn't start. I get a Task "Update attributes for 20 selected products": 0 item(s) are currently being updated.0 item(s) have been scheduled for update. and when I check the log, it says it's 'In Progress' however nothing starts.

Troubleshooting

1.) I've checked the magento_bulk and deleted the rows, hoping there was something stuck however when I queued another task, it gets added to the table and doesn't get pushed into magento_acknowledged_bulk. Is the job supposed to be pushed into this to actually run?

2.) I've checked the Nginx logs and can't see anything which would point to an issue, there was an issue with post_max_size where the limit was being exceeded however I fixed this and restarted PHP, this didn't have any effect on the bulk actions.

3.) I double-checked the permissions and can confirm they're as Magento recommends, there's nothing incorrect with the permissions.

Has anyone encountered this issue before? I looked through some forums however it doesn't look like anyone had a fix for this?

Any help is greatly appreciated!

Jas Singh
  • 154
  • 4
  • 13
  • Which consumer is it which you're expecting to run? Is your cron set up correctly? – benJ Jan 27 '20 at 14:58
  • @benJ I've checked the crontab a few times and it's definitely running, is there any other way of checking? I've tried running ***bin/magento queue:consumers:start product_action_attribute.update*** which hangs pretty much instantly. – Jas Singh Jan 28 '20 at 07:54

4 Answers4

3

After some further investigation and looking around, this change in the env.php file seems to have fixed my issue. Before making the change, I cleared the magento_bulk table and ensured nothing was queued.

I replaced the default cron_consumers_runner with the following:

'cron_consumers_runner' => [
'cron_run' => true,
'max_messages' => 2000,
'consumers' => [
    'product_action_attribute.update',
    'product_action_attribute.website.update',
    'exportProcessor',
    'codegeneratorProcessor'
]]

After changing this, I recompiled and cleared the caches before queuing up a bulk change (I changed the pricing of 20 products) and this job ran instantly.

I hope this helps others!

Jas Singh
  • 154
  • 4
  • 13
  • Is your code work without setup the cron:run command? – Dhaval Vaghela Nov 05 '20 at 11:17
  • @Camit1dk Once you make the change in the env.php file, you can just make the bulk action change in the admin panel and it will run the job. You won't have to manually run 'cron:run' on the server. – Jas Singh Nov 06 '20 at 12:04
  • @PratikKamani It's not present in the env.php file, you have to replace the 'cron_consumers_runner' with the code that I pasted above. – Jas Singh Jan 07 '21 at 10:52
  • @JazzSingh But I not able to find the 'cron_consumers_runner' in the file. – Pratik Kamani Jan 07 '21 at 11:03
  • @PratikKamani If you can't find it, just add my code to the bottom of the env file ensuring you add it before the closing tags and try it that way. – Jas Singh Jan 07 '21 at 13:46
0

According to Magento 2 docs, you should leave consumers empty:

consumers - An array of strings specifying which consumer(s) to run. An empty array runs all consumers.

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

In app/etc/env.php:

'cron_consumers_runner' => [
   'cron_run' => true,
   'max_messages' => 20000,
   'consumers' => [
   ]
],
Stefan Skotte
  • 1
  • 1
  • I don't think this is relevant. The doc says that cron run is enabled by default, you do not need to specify anything in env.php to make it work unless you want to specify something in the configuration but it's not necessary. – Claims Feb 15 '23 at 10:07
0

I had the same issue in Magento 2.4.2. But was fixed after changed the db-schema.xml as describes in this post How to Fix Magneto 2 Bulk Actions Not Starting

Sotmir Laci
  • 84
  • 1
  • 6
0

Actually for me on 2.3.2 this was really simple, there was a cron job in the database that was "stuck" and when I deleted it things started going again. e.g. in the database table cron_schedule look for job_code = 'consumers_runner' with a status = 'running' and delete that row. Hope that helps someone else, took me ages to figure out...

Mooner
  • 1
  • 1
  • 5