Problem/Motivation

Blocks #2429617: Make D8 2x as fast: Dynamic Page Cache: context-dependent page caching (for *all* users!).

The content translation overview inherits the admin route status from the edit route it is extending. That means some of those are considered non-admin routes and are being cached by smartcache.

The missing cache tags for the entity and context for the access check are resulting in a lot of fails with smartcache.

Proposed resolution

Add it. We could also always disable smartcache, but it's actually not that stupid to support it.

Remaining tasks

Add some asserts for cache contexts and tags to the failing tests. See the test fails in #2429617: Make D8 2x as fast: Dynamic Page Cache: context-dependent page caching (for *all* users!) and compare with other related child issues.

User interface changes

None.

API changes

None.

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue category Bug because missing cacheability is a bug.
Issue priority Major because it blocks another major (Smartcache) and getting cacheability right is important.
Prioritized changes The main goal of this issue is performance.
Disruption Not disruptive for core / contrib.

Comments

berdir’s picture

Status: Active » Needs review

Status: Needs review » Needs work

The last submitted patch, 1: content-translation-overview-cacheability-2500013-1.patch, failed testing.

wim leers’s picture

Patch looks great! Just one remark.

+++ b/core/modules/content_translation/src/Controller/ContentTranslationController.php
@@ -78,6 +79,8 @@ public function overview(RouteMatchInterface $route_match, $entity_type_id = NUL
+    $cacheability = CacheableMetadata::createFromRenderArray([]);

No need for this, just

$cacheability = new CacheableMetadata();

will do.

wim leers’s picture

Issue summary: View changes
Issue tags: +blocker

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 1: content-translation-overview-cacheability-2500013-1.patch, failed testing.

Status: Needs work » Needs review

Wim Leers queued 1: content-translation-overview-cacheability-2500013-1.patch for re-testing.

Seems testbot is high and/or drunk.

plach’s picture

Waiting for a fix for #5 to RTBC

berdir’s picture

Fixed and added a small assert. test-only patch should fail, untested ;)

berdir’s picture

Hm, test-only didn't fail...

plach’s picture

Status: Needs review » Needs work

Needs work, I guess :(

lauriii’s picture

"Seems testbot is high and/or drunk." WTF? :D

wim leers’s picture

I suspect something else on the page is already causing that cache context to be added, which would explain the lack of failures. You could choose to force the SimplePageVariant to look only at the cacheability of the render array returned by the controller.

wim leers’s picture

Confirmed by applying content-translation-overview-cacheability-2500013-11-test-only.patch to HEAD, and running this test. It passes. So something else is already adding that cache context.

wim leers’s picture

Status: Needs work » Reviewed & tested by the community

The idea in #17 also won't work; this already is using the SimplePageVariant. So, I don't think there's much more to test here.

plach’s picture

Makes sense, but then why we had test failures in the parent issues?

wim leers’s picture

I had the same question, so I worked on getting the SmartCache patch applying to HEAD again: #2429617-130: Make D8 2x as fast: Dynamic Page Cache: context-dependent page caching (for *all* users!). Let's see what the answer is.

wim leers’s picture

wim leers’s picture

Status: Reviewed & tested by the community » Needs review

So, probably the test is not precise enough. I think it needs to be testing for the presence of some other cache context or some cache tag. Let's figure that out.

berdir’s picture

We now understand why this is fixing smartcache, debugging it together with @plach and @WimLeers:

It's not cache contexts but the cache tag for the entity that we're displaying the overview for. The confusing part was that the cache tag for the entity was displayed in the headers, but smartcache didn't see it. The reason for this is that the access result is added to the response at the end, but that's after smartcache.

That means it is very hard to write useful test coverage in HEAD, since the test assertions here will not fail and the intermediate cacheability metadata is not available anywhere short of unit tests or some sort of event listener that would then print it out again.

We think that it's fine to get this in without that kind of test coverage, we were mostly worried about not understanding what's happening before.

wim leers’s picture

Status: Needs review » Reviewed & tested by the community
plach’s picture

RTBC +1

fabianx’s picture

RTBC + 1

wim leers’s picture

Priority: Normal » Major
fabianx’s picture

Issue summary: View changes

Added beta evaluation.

alexpott’s picture

Status: Reviewed & tested by the community » Fixed

Committed 41cc210 and pushed to 8.0.x. Thanks!

Thanks for adding a beta evaluation.

  • alexpott committed 41cc210 on 8.0.x
    Issue #2500013 by Berdir, Wim Leers, plach: Add cacheability metadata...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.