[drupalMedia] Changing image in media don't immediately change in CKEditor 5 preview: only after 5 minutes

Thanks for the excellent, detailed write-up 🙏 😊

Very interesting edge case!

Metadata about the embedded media is cached up to 5 minutes in the client's browser — see \Drupal\ckeditor5\Controller\CKEditor5MediaController::mediaEntityMetadata():

    return (new JsonResponse($response, 200))
      // Do not allow any intermediary to cache the response, only the end user.
      ->setPrivate()
      // Allow the end user to cache it for up to 5 minutes.
      ->setMaxAge(300);

So can you please confirm that after 5 minutes, the preview in CKEditor 5 does look accurate?

I confirm that after 5min, the preview is refresh.
The change can occur fastly if I desactivate caches in my browser

Great, that at least works as expected then.

I can try to think of a work-around, but this is definitely working as intended for now: great performance for the 99.9% case is more important.

Yes, this is a minor anomaly.
I encountered it while testing the media plugin

I wonder if we should make a config form to manage this?

Could add an option to enable this and number of seconds to cache. Defaults would be enabled and to cache for 300 seconds.

I thought of a reasonable work-around I think 🤓

Can you give this a try?

The last submitted patch, 9: 3355154-9.patch, failed testing. View results →

$cache_tags_checksum = \Drupal::service(CacheTagsChecksumInterface::class);
you are sure of that ?

I ran across this issue with a document media type that is configured to show translations on some display modes via an entity views attach. (I know it sounds complicated, but it was a pretty simple solution for a complex translation need. 😆) If the document was embedded, and then immediately translated, the preview does not update for a bit. I didn't time it, but the 5 minutes mentioned above sounds about right.

So I tried the patch in #9. It did invalidate the cache for the preview upon applying the patch, but it didn't really fix the caching issue on subsequent tweaks to the display mode.

The patch did have an unintended consequence after applying it. It showed all display modes as an option even if the media type did not have that display mode configured. I really don't understand how setting the cachetag checksum could have had that affect, but I thought I would report it for whomever might pick this up.

but it didn't really fix the caching issue on subsequent tweaks to the display mode.

That can be fixed by adding the relevant cache tags for those too.

The patch did have an unintended consequence after applying it. It showed all display modes as an option even if the media type did not have that display mode configured. I really don't understand how setting the cachetag checksum could have had that affect, but I thought I would report it for whomever might pick this up.

That should be literally impossible 😳

Can you consistently reproduce this with the patch applied, and consistently NOT reproduce it without the patch applied? 🙏

That should be literally impossible 😳

I was equally confused by that result.

To make sure it wasn't some oddity in the moderately complex site on which I was working, I tested the patch on a site closer to the standard install. The only additions I made were to add two new display modes for images that were not used by the other default media entity types.

Before applying the patch, an embedded document showed only the "Default" view mode:

After applying the patch, an embedded document showed all enabled view modes even though "Half width" and "Narrow" were not configured display modes for documents.

🤯 Without digging into the JS code, that seems an inexplicable mystery for sure 😄 I'm sure there is some logical explanation. There must be. Let's convert this patch to an MR to find out if the existing test coverage discovers this too. 🕵️

Seemed to cause test failure

Also tagging for issue summary update for once solution is agreed.