Dynamic Page Cache uncachable on Drupal 10.3 with Admin Toolbar Tools and Update modules

In Drupal 10.3 \Drupal\update\Access\UpdateManagerAccessCheck::access is called many times when rendering the toolbar, but not in 10.2.

Can you try reverting the commit from 🐛 Admin page access denied even when access is given to child items RTBC ? Seems like the most likely culprit here.

Added a failing test but GitLab CI is not enabled here so it's a bit harder to demonstrate.

Test passes on 10.2.x and fails on 10.3.x. It also fails after reverting 54a9077a on 10.3.x so it's not 🐛 Admin page access denied even when access is given to child items RTBC .

I narrowed it down to some commit in February then used git bisect to determine 🐛 [regression] Do not bypass route access with 'link to any page' permissions for menu links Fixed to be the cause.

I downloaded Drupal 10.3 using composer and installed using the DDEV and have not made any modifications to the services file to disable caching etc. but in the Drupal core itself, the response header X-Drupal-Dynamic-Cache: is UNCACHEABLE as a logged in user.

Looks like a Drupal core bug?

I have the problem described here 🐛 Fix access checks for bundle permissions to avoid triggering a config validation error Fixed since updating to 10.3.0, I saw these lines in the stacktrace:

#17 /app/web/modules/contrib/admin_toolbar/src/Render/Element/AdminToolbar.php(47): Drupal\Core\Menu\MenuLinkTree->transform(Array, Array)
#18 [internal function]: Drupal\admin_toolbar\Render\Element\AdminToolbar::preRenderTray(Array)

I'm sure that these issues are related. Has anyone checked mrstrelan's comment #6?

#7 maybe not necessarily a core bug, but a change in core has led to this problem (as per #6). Updated the issue title so as not to point the blame on this module.

#8 does not look related to me.

This might be related to 🐛 Don't hide permissions local tasks on bundles when no permissions are defined Needs work , worth trying the MR there.

Ran the test in the MR with 🐛 Don't hide permissions local tasks on bundles when no permissions are defined Needs work in 10.3 and 11.x and it still failed.

@mstrelan so does that mean it's 🐛 [regression] Do not bypass route access with 'link to any page' permissions for menu links Fixed in isolation?

@catch I couldn't cleanly revert that commit but it was the first one that failed with git bisect

I also cherry-picked 719f1684 on to 10.2.x and confirmed the test started failing.

I've narrowed down the permissions required to reproduce this to just administer modules, administer software updates, access toolbar and link to any page.

I think the TL;DR is that this should have always been failing, but we've been bypassing the access check if the user has the "link to any page" permission. The access check is not cacheable because it depends on the allow_authorize_operations setting and AFAIK there is no way to add a cacheable dependency on settings. Possibly we can remove that dependency and tell people they need to clear cache after changing that setting, but that's not ideal either.

Opened ✨ Add a settings cache context Needs work which would also solve this, although it's entirely possible that is a bad idea.

The access check is not cacheable because it depends on the allow_authorize_operations setting and AFAIK there is no way to add a cacheable dependency on settings.

The whole page is going to go away with automatic updates, maybe we can conditionally define the route based on the setting so it just doesn't exist? And then people would have to clear caches to have it available, but that seems OK for something deprecated for removal. Not sure if we have an explicit issue to deprecate it yet.

Good idea, but that causes issues with local tasks and local actions if the routes don't exist, and it seems like a lot of work to also conditionally create those. I've opened ✨ Conditionally disable access to update manager routes Needs work so we can discuss further. Postponing this issue on that one, there will probably be nothing to do here.

This is fixed by ✨ Conditionally disable access to update manager routes Needs work which will be released in 10.3.2.

I am still having this issue on 10.3.2 with Admin Toolbar.

• Fresh 10.3.2
• Login and check page - get MISS, then HIT
• Install Admin Toolbar and give permission to user
• UNCACHEABLE

Thanks for reporting this @b_sharpe. This looks very similar, but in this case it's \Drupal\system\Access\DbUpdateAccessCheck::access that's making it uncacheable. The difference between that access check and \Drupal\update\Access\UpdateManagerAccessCheck::access is that the former only sets the cache max age if the setting is enabled, whereas the latter would set it regardless. I think if you have update_free_access enabled in a hosted environment than you have bigger problems than uncacheable responses, so it's probably not worth following up on this.