Skip to content

Document info-level logging for cache invalidation #2072

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.

Sign up for GitHub

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

Open
umutdogan4291 wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Document info-level logging for cache invalidation #2072

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
fe7caec
document info-level logging for cache invalidation
umutdogan4291 Jan 9, 2026
47975b9
Merge branch 'main' into cache-invalidation-logging
umutdogan4291 Jan 12, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions concepts/framework/http_cache.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -96,6 +96,8 @@ This is because all data loaded in a Storefront controller is loaded in the core

List-type routes are not tagged with all entities returned in the response. This applies to Store API endpoints such as product listings or search results, category listings, or SEO URL listings. These routes instead rely on their TTL as defined by the active HTTP Caching Policy. If the default TTLs are not appropriate for your use case, configure a [custom caching policy](../../guides/hosting/performance/caches.md#fine-tuning-per-route-or-app-hook) for those routes. The reason is that, while it would be technically possible to try to invalidate all affected listings when a single entity changes, doing this at scale is very costly in terms of performance and resources. One entity can appear in many different listings (with different filters, sorting, pagination, etc.). It is also not possible to catch all cases where a change would cause an entity to newly appear in or disappear from a cached listing. Because of this, listing pages cannot guarantee strict, immediate consistency under caching; instead, we accept a small amount of staleness in exchange for predictable performance and stability.

Cache invalidations are logged at the info level to improve observability.
Copy link
Member

@mitelg mitelg Jan 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the SW version, since when we do that could be helpful, as we just will introduce it

Copy link
Author

@umutdogan4291 umutdogan4291 Jan 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense. I will find and add the version when the feature is merged.


## HTTP Cache workflow

**Note:** Workflow described here applies since v6.8.0.0 or since 6.7.6.0 when the `CACHE_REWORK` feature flag is enabled.
Expand Down