Access to certain contextual links may vary not by permissions, but by config overrides: add "config overrides" client-side cache tag

I think the issue title is wrong.

The root cause is not re-rendering/altering. That's a consequence of the root cause.

The root cause is that Contextual Links' client-side caching has the same assumptions as the Contextual Links module had in Drupal 7:

1. contextual links are declaratively/statically defined (in *.links.contextual.yml files)
2. their visibility depends on permissions

1+2 has resulted in contextual.module's implementation roughly looking like this:
For each place where contextual links must be rendered, there is a placeholder containing an ID that identifies all links that should be rendered.

1. We don't render them on the server side, because then it would potentially invalidate the entire page. The server side sends a placeholder to the client side.
2. Some JS on the client side finds these placeholders, and asks the server for a bunch of links (rendered as HTML) to show for that placeholder. Only links that the current user can access are returned.
3. The HTML that the JS receives is cached on the client side, in window.sessionStorage.
4. The client-side cache is invalidated whenever A) a new tab is opened (sessionStorage is bound to tabs), B) whenever the set of permissions for the current user changes, thanks to drupalSettings.user.permissionsHash.

This was implemented in #2136507: Use client-side cache tags & caching to eliminate 1 HTTP requests/page for rendering Contextual Links. You can find more detailed information and related issues there. The implementation introduced in that issue had at least one important flaw/bug in its assumptions, that was there from the very beginning: #2773591: New contextual links are not available after a module is installed.

But now in #2919373, we're violating the assumptions that were fine in #2136507: visibility of links in Contextual Links is no longer only determined by access, but also by whether a config entity that is rendered and has contextual links (Block in this case) has configuration overrides.

Therefore this is no longer correct:

4. The client-side cache is invalidated whenever A) a new tab is opened (sessionStorage is bound to tabs), B) whenever the set of permissions for the current user changes, thanks to drupalSettings.user.permissionsHash.

We need to add C) whenever the set of configuration overrides changes.

In other words: we need a service similar to @user_permissions_hash_generator
(Drupal\Core\Session\PermissionsHashGenerator), but for config overrides: @config_overrides_hash_generator. This would then need to be exposed to the client side just like @user_permissions_hash_generator is exposed to the client side via drupalSettings.uer.permissionsHash. This is the equivalent of a client-side cache tag: a way client-side code to be notified of changes it needs to be able to react to.

Then contextual.es6.js could be updated to not only invalidate its client-side caches when permissions assigned to roles changed, but also when config overrides change. And then Settings Tray would once again work correctly, without the need for hacks.

Updated the issue summary with this. (This is a more detailed version of what I already wrote at #2919373-73: Prevent Settings Tray functionality for blocks that have configuration overrides.)

because this would happen whether or not you had the Settings Try module enabled.

Fair point. Maybe we should rewrite the entire client-side caching logic of Contextual Links!

What if we added the ability for other modules to designate that they needed client-side contextual links to invalidate based on other hashes?

We could, but could a module actually reliably know that?

#2136507: Use client-side cache tags & caching to eliminate 1 HTTP requests/page for rendering Contextual Links assumed all route access checks (for routes used in contextual links) would always only depend on permissions. For the route for the contextual link that Settings Tray is adding, that's not true: it also depends on config overrides (for that particular block entity). But really, an access check could depend on anything. And entity access checks themselves are actually alterable.

Given that, how could a module indicate which "client-side cache tag" hashes should be used for every contextual link?

The more I think about it, the more I think that the approach that I originally proposed and got committed in #2136507: Use client-side cache tags & caching to eliminate 1 HTTP requests/page for rendering Contextual Links 4 years ago (in 4 days!) is just fundamentally flawed.

The more I think about it, the more I think that the approach that I originally proposed and got committed in #2136507: Use client-side cache tags & caching to eliminate 1 HTTP requests/page for rendering Contextual Links 4 years ago (in 4 days!) is just fundamentally flawed.

Because of writing this, I started looking at the patch in #2136507: Use client-side cache tags & caching to eliminate 1 HTTP requests/page for rendering Contextual Links again.

And I noticed something:

       $build['#contextual_links']['custom_block'] = array(
         'route_parameters' => array('custom_block' => $entity->id()),
+        'metadata' => array('changed' => $entity->getChangedTime()),
       );

That metadata key was introduced in #2136507-2: Use client-side cache tags & caching to eliminate 1 HTTP requests/page for rendering Contextual Links, where I wrote:

However, more care is needed in this case, since contextual links for entities may vary depending on the state of the entity. So, the contextual links may only be cached for as long as the entity remains unchanged

[…]
The only way I see we can do this without introducing API changes is to make every entity type that adds contextual links to its entities, also set #contextual_links's 'metadata' key to array('changed' => $entity->getChangedTime()). That immediately resolves the problem.

This is pretty much exactly the problem that we're facing in #2919373: Prevent Settings Tray functionality for blocks that have configuration overrides! Can't we just add the overriddenness to that metadata key? That'd instantly solve it.