-
Notifications
You must be signed in to change notification settings - Fork 9.4k
Open
Labels
Area: FrameworkComponent: CacheIssue: ConfirmedGate 3 Passed. Manual verification of the issue completed. Issue is confirmedGate 3 Passed. Manual verification of the issue completed. Issue is confirmedPriority: P2A defect with this priority could have functionality issues which are not to expectations.A defect with this priority could have functionality issues which are not to expectations.Progress: ready for devReported on 2.4.6-p6Indicates original Magento version for the Issue report.Indicates original Magento version for the Issue report.Reproduced on 2.4.xThe issue has been reproduced on latest 2.4-develop branchThe issue has been reproduced on latest 2.4-develop branchTriage: Dev.ExperienceIssue related to Developer Experience and needs help with Triage to Confirm or Reject itIssue related to Developer Experience and needs help with Triage to Confirm or Reject it
Description
Preconditions and environment
Magento 2.4.6-p6
Cron jobs, responsible for reindexing tasks, are primarily using DeferredCacheContext for collecting tags and entities for cache flushing and further process them later at once.
The cache context object has an internal pointer of nesting, and pushes registered tags/entities only if the pointer is equal to 1. That's understandable, having nesting hierarchy logics, only last commit
must take the action.
What will happen if some of cron jobs finish erroneously with doing start
and incrementing the level pointer but never commiting?
Steps to reproduce
- Make
indexer_reindex_all_invalid
cron job to fail every time (throw an exception in the job). - Do some changes in a products to put them to partial reindex queue.
- Keep an eye what cache tags have been invalidated in the
var/log/cache.log
after cron runs.
Expected result
Every product/related categories tags, such as cat_p_*
, cat_c_*
are pushed for invalidation.
Actual result
No cache tags are invalidated by partial cron reindex.
Additional information
No response
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”.
Metadata
Metadata
Assignees
Labels
Area: FrameworkComponent: CacheIssue: ConfirmedGate 3 Passed. Manual verification of the issue completed. Issue is confirmedGate 3 Passed. Manual verification of the issue completed. Issue is confirmedPriority: P2A defect with this priority could have functionality issues which are not to expectations.A defect with this priority could have functionality issues which are not to expectations.Progress: ready for devReported on 2.4.6-p6Indicates original Magento version for the Issue report.Indicates original Magento version for the Issue report.Reproduced on 2.4.xThe issue has been reproduced on latest 2.4-develop branchThe issue has been reproduced on latest 2.4-develop branchTriage: Dev.ExperienceIssue related to Developer Experience and needs help with Triage to Confirm or Reject itIssue related to Developer Experience and needs help with Triage to Confirm or Reject it