Entity display plugin "Rendered Entity" should only add cache key if the entity is render cached

+++ b/src/Plugin/EntityBrowser/FieldWidgetDisplay/RenderedEntity.php
@@ -76,7 +76,10 @@ class RenderedEntity extends FieldWidgetDisplayBase implements ContainerFactoryP
     $build['#entity_browser_suppress_contextual'] = TRUE;
+    $build['#cache']['keys'][] = $entity->bundle();
+    $build['#cache']['keys'][] = $entity->id();
     $build['#cache']['keys'][] = 'entity_browser';
+    $build['#cache']['tags'][] = $entity->bundle() . ':' . $entity->id();
 
     return $build;
   }

I'm not sure I fully understand, but those are not valid cache tags and $build should already contain all the necessary cache tags by default.

I did not run into a similar problem. I think the issue is with entities that don't use render caching themself like paragraphs library items.

The correct fix is IMO to only add the extra cache key if there are already cache keys or it is cached _only_ by this key.

I just ran into this today with some (many) reference fields to media entities using the Rendered Entity plugin. The patch in #6 seems to fix the problem. What I saw, stepping through the debugger, was that the key was getting set before it ever got handed off to the renderer, and since the key was just 'entity_browser', the media item for the first field was reused for all the other fields. Will test it some more, but it seems good.

> was that the key was getting set before it ever got handed off to the renderer

The cache key has to be set before the renderer. This happens with entity types that have render caching disabled, so their view builder doesn't set a #cache key, and then entity browser sets them all to the same one. media entities have render caching enabled by default, but it's something that can be disabled, which might be done in your case because they're not reused or might depend on the parent entity or so.

@Berdir,
Thanks for the note! I was about to argue that we don't disable caching and I stepped through our code and found that we do. We have a bug that errantly cleared $build['#cache'] in a hook_entity_build_defaults_alter while trying to add in a cache tag. So yay for this bug uncovering the underlying issue.

The patch in #6 worked great for us and the solution makes sense to me (i.e. adding an 'entity_browser' cache key when no other keys are present will result in overly aggressive caching). We're using paragraphs, so that part of the theory checks out as well.

I confirm patch #6 works perfectly, It would be great to add this fix to next release.

Another vote of confidence for #6: it fixed my issue with Paragraphs Library.

Committed.