Magento 2.3 – Fix Bulk Product Attribute Update Error

cronmagento2.3queue

Trying to do a bulk product attribute update in the magento GUI and feedback is that the message is queued. Messages in the database table queue_message seem right, the logs and a manual php bin/magento cron:run have the message:

queue:consumers:start [–max-messages MAX-MESSAGES] [–batch-size BATCH-SIZE] [–area-code AREA-CODE] [–pid-file-path PID-FILE-PATH] [–]

In State.php line 136:

Area code is already set

So for now I've commented out that check in /http/vendor/magento/framework/App/State.php and the jobs run.

It does not seem right to hack the magento core code, but I have done this before for php bin/magento catalog:images:resize for that specific job to skip that and it worked fine – but that was a job I'd expect to run one time only and could revert the change. This is required to be constantly running and to process exports and attribute updates.

Is there any advice you could give me to get this feature working without having to hack the core please?

Best Answer

This is usually due to some other bit of code setting the areaCode before core is trying to set it. Usually because it is trying to be set in __construct() some where. With how dependency injection works, all objects are loaded and their constructors are ran, even if your not using that object. I would check that the areaCode is not being set in a __construct()

Related Solutions

Should Standard Cron Jobs Always Be Running in Magento 2?

Providing at least a temporary work around to the problem, to avoid hammering your MySQL server. Git issue describing the problem

At least part of the problem comes down to the cron_schedule table. I'd recommend doing a select count(*) from cron_schedule; and if that returns more than a few hundred, then you have the issue. For me, that query returned 208,046 on a server that has been running for only a few weeks.

If you have the problem then run this query to delete everything in that table, except the recent rows delete from cron_schedule where scheduled_at < date_sub(now(), interval 1 hour);

Then run the count query again and it should be waaaay lower. Mine went from 208k to 252.

After running that query I set all 3 standard crons back to the standard once per minute, and like magic they all 3 run almost instantly. Back to normal as far as i can tell.

In the github issue, another user suggests adding that query to crontab to prevent the table from growing again.

0 * * * * <path_to_mysql_bin_dir>/mysql <magento_db_name> -e "delete from cron_schedule where scheduled_at < date_sub(now(), interval 1 hour)"

The last response from the Magento team on the issue was in September saying they cannot reproduce the issue, but a number of users have followed up saying they experience the same thing, including myself. So hopefully they fix this so this hack can be removed.

EDIT: To use that command on the crontab you'll need to pass your credentials to MySQL in some way. See my comment below if you're on a dedicated VM or server and want to put your user/pass on crontab, otherwise you'll need to set up a MySQL credentials file. And you can use which mysql to find the path to your mysql binary directory.

Best Answer

Related Solutions

Should Standard Cron Jobs Always Be Running in Magento 2?

Related Topic