Contrib.social

Stale cache when latest revision is published (content moderation)

Open on Drupal.org →
Created on 29 July 2023, over 1 year ago
Updated 10 August 2023, over 1 year ago

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.

  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.
🐛 Bug report
Status

Closed: won't fix

Version

1.0

Component

Code

Created by

🇺🇸United States weekbeforenext Asheville, NC

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @weekbeforenext
  • Comment over 1 year ago →
    🇺🇸United States weekbeforenext Asheville, NC

    Discovered another dependency which is Memcached.

  • Status changed to Closed: won't fix over 1 year ago
  • Comment over 1 year ago →
    🇺🇸United States weekbeforenext Asheville, NC

    The patch in 🐛 Transaction support for cache (tags) invalidation Needs review seems to have resolved this issue.

  • Comment over 1 year ago →
    🇺🇸United States Jody Lynn

    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.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024