-
Notifications
You must be signed in to change notification settings - Fork 9.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cleanup of cron_schedule database table doesn't cleanup non-existing jobs #38217
Comments
Hi @hostep. Thank you for your report.
Join Magento Community Engineering Slack and ask your questions in #github channel. |
@magento I am working on this |
Hi @engcom-Dash. Thank you for working on this issue.
|
Hi @hostep Thanks for reporting and collaboration. It is not advisable to disable MSI modules. As per the adobe dev docs, Disabling the Inventory Management modules can cause an unstable system and result in various issues. Please refer the below devdocs for more information : https://experienceleague.adobe.com/docs/commerce-admin/inventory/get-started/install-update.html Thanks |
@engcom-Dash: that's not the point, this was just the easiest way I could find to demonstrate the problem 😉 This will most likely happen in the real world where you had a third party module installed (which contains a cronjob) for a couple of months and then decide to remove it again. Afterwards, you'll still find entries from that no longer existing module in your Please re-read the description and if it's not clear, try to pull in one of your colleagues and see if they understand it better. And if it's still not clear, then let me know what's not clear so I can try to describe it better. |
Hi @hostep Thanks for reporting and collaboration. Verified the issue in magento 2.4 dev instance and the issue is reproducible. After disabling MSI modules , seeing the inventory_in_store_pickup_sales_send_order_notified_emails in the table with status success when we run the cron job and checked in the cron_schedule table. |
✅ Jira issue https://jira.corp.adobe.com/browse/AC-10910 is successfully created for this GitHub issue. |
✅ Confirmed by @engcom-Dash. Thank you for verifying the issue. |
❌ You don't have permission to export this issue. |
Preconditions and environment
Steps to reproduce
Explanation below how to trigger this with a cronjob from inside core Magento. But the most likely cases will come from 3rd party modules containing cronjobs, that were installed for a while and then removed again.
cron_schedule
table and notice that the jobinventory_in_store_pickup_sales_send_order_notified_emails
is mentioned many times with statussuccess
app/etc/config.php
and runbin/magento setup:upgrade
cron_schedule
table againExpected result
It's expected that all jobs that were successful and having run more than 60 minutes ago are removed from the
cron_schedule
table.Actual result
See that there are still jobs
inventory_in_store_pickup_sales_send_order_notified_emails
in the table with status success and being older then 60 minutes. Those don't get cleaned up because the MSI modules are no longer active and callinggetJobs()
over here doesn't return jobs from inactive (or removed) modules.Additional information
Ideally, the cronjob cleanup should also figure out which jobs are in the
cron_schedule
table that are no longer found in the system and clean those up as well.Or maybe this can be added in the existing Recurring data script that exists in the Magento_Cron module, as then it doesn't need to be checked every minute when the cron actually runs. Since removing and disabling modules requires a
bin/magento setup:upgrade
call anyway, it might be a good idea to only then check for outdated entries in that table and remove them...And since the
cron_schedule
table receives a lot of queries the entire day, it's beneficial to performance that it contains as few rows as possible. Old data should be cleaned up automatically.I found this in a shop where we have hundreds of entries from 2021 in the
cron_schedule
table for jobs that for a long time no longer existed.Release note
No response
Triage and priority
The text was updated successfully, but these errors were encountered: