Problem/Motivation

Layout Builder is attaching incorrect cache dependencies to certain components/sections, which leads to:

  • stale content being rendered under some conditions
  • overly broad caching (pages being invalidated more often than needed)
  • data from the wrong entity/context leaking into other pages.

In a project, it was observed that:

  • a inline block or component rendered in a Layout Builder section does not change when the underlying entity/field is updated, until caches are manually cleared, or
  • a page picks up cache tags from an unrelated entity and gets invalidated unnecessarily.

After debugging, it was found that Layout Builder adds the wrong cache dependencies for some components, causing incorrect cache metadata to end up on the final render array.

Steps to reproduce

  1. Enable Layout Builder for a content type.
  2. Create a node and configure its layout with one or more components (e.g. blocks / inline blocks / views blocks).
  3. Visit the node; confirm it is cached (normal page cache + dynamic page cache).
  4. Change the underlying data for one of the components (e.g. update a referenced entity, block, or field that should affect the component).
  5. Observe whether the Layout Builder page reflects the change or not.

Actual result

  • The Layout Builder page does **not** always get invalidated when the underlying data changes.
  • Or, the page gets invalidated for unrelated changes because cache tags / contexts are wrong.
  • Cache metadata inspection (e.g. using Webprofiler / `debug:cache` / render debugging) shows Layout Builder attaching the wrong cache dependencies to the layout or components.

Expected result
Layout Builder should set cache tags/contexts/max-age correctly for:
- each section,
- each component,
- and the overall layout,
so that:
- pages are invalidated when their underlying data changes, and
- unrelated changes do not cause unnecessary cache invalidations.

Proposed resolution

The attached patch:

  • Adjusts the way Layout Builder calculates and attaches cache dependencies for its components/sections.
  • Ensures that:
    • The correct entities/fields are added as cacheable dependencies.
    • Unrelated entities are not incorrectly added as dependencies.
  • Aims to make rendered Layout Builder pages track the right cache tags and contexts, fixing the observed staleness/over-invalidation issues.

The change is deliberately scoped to the cache metadata handling in Layout Builder.

Remaining tasks

  • Review the patch and confirm the cache dependency logic is correct and aligns with current core cache APIs (`CacheableDependencyInterface`, `Cache::mergeDependencies()`, etc.).
  • Add/update tests that:
    • Reproduce the stale/over-invalidating behavior without the patch.
    • Confirm the correct behavior with the patch.

Comments

ionut.stan created an issue. See original summary.

quietone’s picture

Version: 10.3.x-dev » 11.x-dev

Hi, thank you for the report and a fix.

Hi, in Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies. Thanks.

Can you confirm this happens on 11.2.x, 11.3,x or 11.x? Thanks

quietone’s picture

Title: Layout Builder: Fix wrong cache dependencies on layout components » Fix wrong cache dependencies on layout components
sourav_paul’s picture

Checking...

sourav_paul’s picture

I’ve validated this behavior on Drupal 11.x & 11.3 and can confirm the issue is no longer reproducible. When modifying block content within Layout Builder, the updates propagate immediately to the rendered page without requiring a cache clear or page reload.

sourav_paul’s picture

danielveza’s picture

Status: Active » Postponed (maintainer needs more info)

Setting to postponed while we wait for steps to replicate with a vanilla D11 instance. You mentioned that you noticed this in a project, could it be that custom code or contrib modules are interferring here?

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.