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.

Node revisions page showing the latest published revision but not as the 'Current revision'.

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.

  1. Create a published article.
  2. Edit the article, make a simple text change, set moderation state to "Draft" (or an unpublished state).
  3. View the published article.
  4. Edit the article, make a simple text change, set moderation state to "Published" (or published state).
  5. View the published article.
  6. Observe that the latest published version is not displayed.
  7. Click on the "Revisions" tab.
  8. Observe that the latest published revision is not showing "Current revision" in the "Operations" column.
  9. Click on the "Set as current revision" button for the latest published revision.
  10. Observe that the "Access Denied" page is displayed.
  11. Clear site cache.
  12. View the article.
  13. Observe that the latest published revision is displayed.
  14. Click on the "Revisions" tab.
  15. Observe that the latest published revision is showing "Current revision" in the "Operations" column.
CommentFileSizeAuthor
revisions_page_latest_published_revision_cache_lag.png184.09 KBweekbeforenext

Comments

weekbeforenext created an issue. See original summary.

weekbeforenext’s picture

weekbeforenext
Primary language English
Location Asheville, NC
commented
Issue summary: View changes

Discovered another dependency which is Memcached.

weekbeforenext’s picture

weekbeforenext
Primary language English
Location Asheville, NC
commented
Status: Active » Closed (won't fix)
Related issues: +#2996615: Transaction support for cache (tags) invalidation

The patch in #2996615: Transaction support for cache (tags) invalidation seems to have resolved this issue.

jody lynn’s picture

jody lynn
she/her
Primary language English
commented

Thanks @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.