Explicitly flush isolated caches by key for content updates #20509
+161
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Prerequisites
Description
When editing documents and media, the isolated caches are explicitly updated by the repository cache policy (here) - but only by ID. Any document and media entities cached by key are flushed by the
ContentCacheRefresher
andMediaCacheRefresher
(here and here, respectively).Unfortunately, the by-key flushing comes too late for any notification handlers tied to the "Saved" notifications (
ContentSavedNotification
andMediaSavedNotification
). If one attempts to fetch the saved document or media by key from the content or media services in these notification handlers, the returned entity will consistently be the one previously loaded into the cache - that is, the previous version.Note: This is seemingly not an issue for members, even though they share the same repository base.
To fix this, I have replicated the cache flushing performed by the content and media cache refreshers in the document and media repositories.
A temporary fix
This is at best a patch to work around the underlying problem, which is likely linked to the use of sub-repositories in the document and media repositories (here and here, respectively).
We need to plan for a less fragile solution in the future, but this will suffice for the time being.
Note: The member repository does not have a sub-repository, which is probably why we don't see the issue for members.
Testing this PR
Include the notification handlers below, and test this PR by changing the names of documents and media.
Without this PR, the log output from the handlers will look like this (sampled from documents, but media looks the same):
With this PR, the output looks like this:
The subtle difference is the very last line of the logging output; the "Saved" notification outputs the previous name when this PR is not applied.
I have also included a notification handler to validate that members are not affected by this issue.
Content notification handler
Media notification handler
Member notification handler