From fe7caecf616ee02c0622623103a406e9c19869ca Mon Sep 17 00:00:00 2001 From: Umut Dogan Date: Fri, 9 Jan 2026 16:24:38 +0100 Subject: [PATCH 1/3] document info-level logging for cache invalidation --- concepts/framework/http_cache.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/concepts/framework/http_cache.md b/concepts/framework/http_cache.md index 62a917abc..8e034393b 100644 --- a/concepts/framework/http_cache.md +++ b/concepts/framework/http_cache.md @@ -94,6 +94,8 @@ For more information about Store API cache invalidation, you can refer to the [C This is because all data loaded in a Storefront controller is loaded in the core via the corresponding Store API routes and provided with corresponding cache tags. So the tags of the HTTP cache entries we have in the core consist of the sum of all Store API tags generated or loaded during the request. Therefore, the invalidation of a controller route is controlled over the Store API cache invalidation. +Cache invalidations are logged at the info level to improve observability. + ## 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. From 207824195a38f10de8fa5ec837a6a65002fb28f7 Mon Sep 17 00:00:00 2001 From: Umut Dogan Date: Wed, 21 Jan 2026 09:52:30 +0100 Subject: [PATCH 2/3] Update http_cache.md --- concepts/framework/http_cache.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/concepts/framework/http_cache.md b/concepts/framework/http_cache.md index 673a45463..069f324c1 100644 --- a/concepts/framework/http_cache.md +++ b/concepts/framework/http_cache.md @@ -96,7 +96,7 @@ 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. +Since v6.7.7.0, cache invalidations are logged at the info level and can be enabled or disabled via the `tag_invalidation_log_enabled` configuration option. ## HTTP Cache workflow From 077930262d570e0117aa4708524b10e4c7afab21 Mon Sep 17 00:00:00 2001 From: Umut Dogan Date: Wed, 21 Jan 2026 10:33:16 +0100 Subject: [PATCH 3/3] Update http_cache.md --- concepts/framework/http_cache.md | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/concepts/framework/http_cache.md b/concepts/framework/http_cache.md index 069f324c1..ece6497e1 100644 --- a/concepts/framework/http_cache.md +++ b/concepts/framework/http_cache.md @@ -96,7 +96,16 @@ 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. -Since v6.7.7.0, cache invalidations are logged at the info level and can be enabled or disabled via the `tag_invalidation_log_enabled` configuration option. +Since v6.7.7.0, cache invalidations logging at info level can be enabled or disabled via the `tag_invalidation_log_enabled` configuration option. +It is disabled by default. + +```yaml +# /config/packages/shopware.yaml +shopware: + cache: + invalidation: + tag_invalidation_log_enabled: false +``` ## HTTP Cache workflow