Cleanup of cron_schedule database table doesn't cleanup non-existing jobs

[hostep]

Preconditions and environment

• Magento version 2.4.6-p3 (but most likely all versions will be affected)

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.

1. Have a Magento shop with MSI modules enabled
2. Have a working crontab and have it running for a couple of hours
3. Inspect the cron_schedule table and notice that the job inventory_in_store_pickup_sales_send_order_notified_emails is mentioned many times with status success
4. Now, disable all MSI modules in app/etc/config.php and run bin/magento setup:upgrade
5. Keep the crontab running for a few more hours
6. Inspect your cron_schedule table again

Expected 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 calling getJobs() 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

• Severity: S0 - Affects critical data or functionality and leaves users without workaround.
• Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
• Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
• Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
• Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.

[m2-assistant]

Hi @hostep. Thank you for your report.
To speed up processing of this issue, make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, Add a comment to the issue:

• @magento give me 2.4-develop instance - upcoming 2.4.x release
• For more details, review the Magento Contributor Assistant documentation.
• Add a comment to assign the issue: @magento I am working on this
• To learn more about issue processing workflow, refer to the Code Contributions.

---

Join Magento Community Engineering Slack and ask your questions in #github channel.
⚠️ According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.
🕙 You can find the schedule on the Magento Community Calendar page.
📞 The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket.

[ananth-iyer]

@magento I am working on this

[m2-assistant]

Hi @engcom-Dash. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: 👇

• 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
• 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue.
• 3. Add Area: XXXXX label to the ticket, indicating the functional areas it may be related to.
• 4. Verify that the issue is reproducible on 2.4-develop branch
     Details

     - Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
     - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
     - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

[engcom-Dash]

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

[hostep]

@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 cron_schedule table and that is polluting the database.

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.

[engcom-Dash]

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.

Please refer the attached screenshots.