6

How can we debug or reproduce the following problem:

We noticed that the tax_class_id of almost all products (96%) get reset to 0 so we mass updated the tax class of the products back to normal. The next day it was reset to 0 again. We started monitoring the attribute value with the following query:

select count(*)
from catalog_product_entity_int
where value = 0
  and store_id = 0
  and attribute_id = (select attribute_id from eav_attribute where attribute_code = 'tax_class_id')

Due to the monitoring we figured out that this reset starts at 02:00 AM and continues for 3 hours until almost all products tax class is set to 0.

This behavior occurs on our testing instance as well at the same time but less products are affected (20%).

What we did so far:

  • Our first thought was that it might be a cronjob that is causing the problem because it occurs every day at the exact same time. So I checked cronjobs running on the server but we only have the Magento cronjobs running and of them no one runs at 02:00 AM.

  • We thought it might be due to our import via the rest api but we have a rest logging active and this is not affecting it. On the import the correct tax_class_id is pushed to Magento and Magento returns the correct value. As well the import runs later.

  • We thought maybe someone acquired access to the admin backend or server so we checked our access logs but there are no abnormalities.

  • I checked the Magento logs but I didn't find anything that could lead to a clue.

  • I checked our custom modules whether we overwrite the tax_class_id somewhere but we don't.

Is there any way to debug this behavior?

  • 2
    Try to reproduce locally. For this, copy the production database and set the time to 1:59 AM, let crons run etc. – Alex Jul 11 at 17:37
1

The comment of Alex was a very good Idea and is a way to debug this.

I did set my time to 1:59 AM and let my cron run. At the same time I let a watcher running on my database with the query so I can monitor if the values change.

I noticed that it indeed was a cron responsible for the changes and started to let cron run each one individually with n98-magerun2 (n98-magerun2 sys:cron:run cron_name) to figure out which cron it is specifically (starting with custom crons).

Tip for debugging a cronjob:

For easier debugging I dumped the affected table(s) and additionally cron_schedule so I can reset them after each run or whenever needed. This is especially useful for a cron that only runs once a day because Magento will mark it as success after running it and it won't run again until next day. To prevent having to set the date every time a day further I recommend the dump.

What cleared the tax_class_id:
The cronjob that caused the error was checking every night the products for there news_from_date and news_to_dateattributes. If the current day is between the dates it did set our custom attribute is_new to true otherwise to false.
To have a bit better performance only the attributes news_from_date, news_to_date and is_new were loaded with
$productCollection->addAttributeToSelect(['news_from_date', 'news_to_date', 'is_new']);
Then is_new was either set to true or false but when saving the product tax_class_id was set to it's default value (0) because it was not set for the product.

  • 1
    You might want to shortly elaborate what cleared the tax class id – Alex Jul 21 at 7:41

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.