Problem/Motivation
When using Content Moderation, Memcached, and the Diff module, users can create a published revision that isn't immediately recognized as the "current revision" in a node page view or the node revisions page view.
The latest published revision is listed on the node revisions page, but the "Set as current revision" button for that revision leads to an access denied page.
Clearing the site cache resolves the issue.
Uninstalling the Diff module also resolved the issue.

Steps to reproduce
Note: Content Moderation could be a factor. "Published" and "Draft" in the steps refers to content moderation states. "Published" is published and "Draft" is unpublished.
- Create a published article.
- Edit the article, make a simple text change, set moderation state to "Draft" (or an unpublished state).
- View the published article.
- Edit the article, make a simple text change, set moderation state to "Published" (or published state).
- View the published article.
- Observe that the latest published version is not displayed.
- Click on the "Revisions" tab.
- Observe that the latest published revision is not showing "Current revision" in the "Operations" column.
- Click on the "Set as current revision" button for the latest published revision.
- Observe that the "Access Denied" page is displayed.
- Clear site cache.
- View the article.
- Observe that the latest published revision is displayed.
- Click on the "Revisions" tab.
- Observe that the latest published revision is showing "Current revision" in the "Operations" column.
| Comment | File | Size | Author |
|---|---|---|---|
| revisions_page_latest_published_revision_cache_lag.png | 184.09 KB | weekbeforenext |
Comments
Comment #2
weekbeforenextDiscovered another dependency which is Memcached.
Comment #3
weekbeforenextThe patch in #2996615: Transaction support for cache (tags) invalidation seems to have resolved this issue.
Comment #4
jody lynnThanks @weekbeforenext. We have been dealing with a similar bug, possibly the same thing.
We have only been able to reproduce it on our live site where we can't clear the cache to confirm it. It did sound like it was possible that your observation that disabling diff was unrelated and just that disabling anything cleared the cache.
For us the issue is intermittent, consistent with a race condition. Sometimes an editor saves a node as published revision, but then is redirected to the 'latest' tab as if there were a draft revision. The 'latest' tab then gives a 403 as there is no draft revision, and the revisions tab shows that the latest published revision is not the 'current' revision as you showed. The changes made are not published, and when the editor tries to edit the page again they can get the error that 'the content has been edited by another user' as well.
The timing of this bug started happening for us at the same time that we were adding a bunch of additional logic on node saves to customize which cache tags were clearing depending on which fields were modified. So perhaps adding in more logic or more cache tags to invalidate led to to this race condition becoming more likely to fail.
We are not able to reproduce the bug outside prod, but we'll follow your advice and try that patch, as a race condition related to cache tags sounds about right.