Refresh invalidated caches nightly

[fredden]

Description

When certain actions are taken in the admin, related caches are marked as invalid. Manual action is required to refresh these caches. This is often okay as the action which invalidated the cache(s) was performed by an admin user. However there are some automated actions which can invalidate caches. In this case, caches may remain in an invalidated state for long periods of time, resulting in hard-to-diagnose (unexpected) behaviour.

This pull request introduces a cronjob which will refresh all invalidated caches.

Manual testing scenarios

1. Make a configuration change in the admin
2. Observe that the Configuration and Full Page caches are marked as invalidated
3. Run the (existing) backend_clean_cache cronjob
4. Observe that the Configuration and Full Page caches are still marked as invalidated
5. Run the backend_refresh_invalidated_caches crobjob (which is introduced in this pull request)
6. Observe that no caches are marked as invalidated

Contribution checklist

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• README.md files for modified modules are updated and included in the pull request if any README.md predefined sections require an update
• All automated tests passed successfully (all builds are green)

[m2-assistant]

Hi @fredden. Thank you for your contribution
Here are some useful tips how you can test your changes using Magento test environment.
Add the comment under your pull request to deploy test or vanilla Magento instance:

• @magento give me test instance - deploy test instance based on PR changes
• @magento give me 2.4-develop instance - deploy vanilla Magento instance

❗ Automated tests can be triggered manually with an appropriate comment:

• @magento run all tests - run or re-run all required tests against the PR changes
• @magento run <test-build(s)> - run or re-run specific test build(s)
  For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names. Allowed build names are:

1. Database Compare
2. Functional Tests CE
3. Functional Tests EE,
4. Functional Tests B2B
5. Integration Tests
6. Magento Health Index
7. Sample Data Tests CE
8. Sample Data Tests EE
9. Sample Data Tests B2B
10. Static Tests
11. Unit Tests
12. WebAPI Tests
13. Semantic Version Checker

You can find more information about the builds here

ℹ️ Run only required test builds during development. Run all test builds before sending your pull request for review.

For more details, review the Magento Contributor Guide documentation.

⚠️ According to the Magento Contribution requirements, all Pull Requests 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 Pull Requests 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.

✏️ Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time.

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time.

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time.

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time.

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time.

[dudzio12]

I observe similar issues. When backend_clean_cache cron job runs, it leaves some records without tags with create time from the time cron was running.

This is critical because broken cache records contains some crucial products information. We cannot clean them by saving product or any Magento logic, because of the lack of tags. It won't clean even on cache:clean action, because it has no MAGE tag too. The only way to clear it is running cache:flush.

I'm not sure if flush action is a way to go though, I'll try to dig it a little bit more.

[fredden]

@magento run all tests