How to debug that tax_class_id gets overwritten

Question

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?

Answer 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.