Cache tag invalidation skipped due to failed database transaction

Question

The goal is to guarantee that authenticated users always receive up‑to‑date dynamic page cache content without requiring site builders to manually add the 'user' cache context.

This raises constraints around potential performance overhead, backward compatibility for existing sites that rely on custom cache contexts, and the pending core decision about whether such enforcement should be automatic.

Because the core has not yet decided to enforce automatic cache context variation for authenticated users when using dynamic page caches, it remains unclear whether the benefit of guaranteed freshness outweighs the possible impact on cache hit rates and resource consumption.

Should Drupal core automatically apply the 'user' cache context to dynamic page cache for authenticated users?
What performance trade‑offs would arise from enforcing this context variation on high‑traffic sites?
How would this change affect existing implementations that already manage cache contexts customly?

Tasadduq Burney · Answer

Drupal core should not automatically apply the user cache context to the dynamic page cache for all authenticated users. Doing so would prioritize absolute data freshness at the cost of fundamentally breaking the efficiency of the caching layer.

The Trade-off: Correctness vs. Performance
In Drupal's cache API, contexts determine variation (who sees what), while tags determine invalidation (when to clear). If a page displays user-specific data but fails to declare the user context, it is a bug in the content's cacheability metadata, not a failure of the cache system.

Performance Impacts on High-Traffic Sites

Cache Hit Rate Collapse: Forcing the user context creates a unique cache entry for every single authenticated user. On a site with 10,000 active users, a single page that could have been shared across all users (or groups of users) now requires 10,000 separate entries.
  Storage Inflation: The database or memory store (Redis/Memcached) would experience a massive increase in key-value pairs, potentially leading to eviction of other critical cached data and increased I/O overhead.
  Resource Consumption: The CPU overhead of generating and storing thousands of nearly identical page variations outweighs the benefit of avoiding manual context declaration.

Impact on Existing Implementations
For sites already managing cache contexts customly, automatic enforcement would not overwrite their specific logic—since contexts are merged—but it would render their optimizations moot. If a developer specifically used user.roles to allow all "Editors" to share a cache entry, a forced user context would override this efficiency, forcing per-user variation regardless of role similarity.

Recommended Approach
Rather than a blanket enforcement, the following strategies maintain both correctness and performance:

Granular Contexts: Use user.roles or user.permissions when content varies by group rather than individual.
  Lazy Builders: Use #lazy_builder callbacks for highly dynamic, user-specific fragments. This allows the rest of the page to remain cached globally while only the user-specific part is rendered dynamically.
  Automated Testing: Use kernel tests to assert that any code producing user-specific output correctly bubbles up the user cache context.

Diagnostic Note: To provide a more specific recommendation for your environment, please clarify if you are seeing "leaked" content (User A seeing User B's data) or if this is a theoretical architectural concern.

Cache tag invalidation skipped due to failed database transaction

1 answer

The Trade-off: Correctness vs. Performance

Performance Impacts on High-Traffic Sites

Impact on Existing Implementations

Recommended Approach

Your perspective belongs here.

0 question comments