Multiple concurrent current revisions

Can you provide some more information around how you were able to produce this and if you can easily reproduce it?
It sounds like you have a multilingual site? Can you confirm, and give details about that?

"untranslatable fields can't be changed while editing not the current revisions." is a valid error when using a module such as Content Moderation to create pending revisions, then untranslatable fields (fields that are the same across all translations) can only be edited in the current revision.

Same problem on our site.

We are also using redis, content moderation, APCU, D 8.5.6, no multilingual though. We've been fighting this issue for a few years now (pretty much since D 8.0.0). It only happens in production, which makes me thing it requires the site either being under load, or it requires multiple people to be publishing concurrently on the site.

I would be more than happy to also share of list of all modules installed, and all services being used to help debug.

Adding a screenshot. Also spoke with editorial, typically one editor will control one instance of a content type at a time. I'm also adding our composer.json to help triage.

    "chosen": "1.5.1",
    "composer/installers": "v1.5.*",
    "cweagans/composer-patches": "^1.6",
    "donatj/phpuseragentparser": "dev-os_version_detection",
    "drupal-composer/drupal-scaffold": "2.4.0",
    "drupal/core": "8.5.*",
    "drupal/admin_toolbar": "1.16",
    "drupal/bootstrap": "3.0-beta3",
    "drupal/chosen": "2.5.0",
    "drupal/config_update": "1.5.0",
    "drupal/crop": "1.0.0",
    "drupal/ctools": "3.0.0-alpha27",
    "drupal/embed": "1.0.0-rc3",
    "drupal/entity": "1.0.0-beta4",
    "drupal/entity_browser": "1.5",
    "drupal/entity_embed": "1.0-beta2",
    "drupal/entity_reference_revisions": "1.5.0",
    "drupal/features": "3.7.0",
    "drupal/field_group": "3.0.0-beta1",
    "drupal/file_entity": "2.0.0-beta6",
    "deviantintegral/flysystem": "8.1.0-patch3+alpha4",
    "deviantintegral/flysystem_s3": "8.1.0-patch8+alpha1",
    "drupal/imageapi_optimize": "2.0-alpha2",
    "drupal/image_widget_crop": "1.4.0",
    "drupal/inline_entity_form": "1.0.0-rc1",
    "drupal/media_entity": "1.3.0 as 8.1.3",
    "drupal/media_entity_image": "1.2.0",
    "drupal/Media_entity_twitter": "1.3.0",
    "drupal/metatag": "1.0-beta9",
    "drupal/migrate_plus": "2.0-beta1",
    "drupal/migrate_source_json": "2.x-dev#bf7d94e08c21c1a81a635d238db915aab69b3d47",
    "drupal/migrate_tools": "2.0-beta1",
    "drupal/monolog": "1.0-alpha2",
    "drupal/paragraphs": "1.3.0",
    "drupal/password_policy": "3.x-dev#451c37bd4edfe87d52f02c47f266e17890a577f3",
    "drupal/pathauto": "1.0.0-rc1",
    "drupal/redis": "1.0.0-beta1",
    "drupal/remote_stream_wrapper": "1.0.0 as 8.1",
    "drupal/special_menu_items": "1.x-dev#ee6c072",
    "drupal/tablefield": "2.0-alpha1",
    "drupal/token": "1.1.0",
    "twig/extensions": "v1.5.1",
    "drupal/twig_extensions": "1.1.0",
    "drupal/twig_temp": "1.1.0",
    "drupal/url_embed": "1.x-dev",
    "drupal/zurb_foundation": "6.0.0-alpha1",
    "drush/drush": "^9.0",
    "drupal/entity_form_monitor": "1.0-alpha3",
    "drupal/queue_ui": "2.x-dev#f51ebeaee7648742602ca870bad721bf9f174ba2",
    "drupal/views_infinite_scroll": "1.5",
    "drupal/anchor_link": "1.3",

Thank you for reporting this problem. We rely on issue reports like this one to resolve bugs and improve Drupal core.

There hasn't been any new info or reports of this in six years, and it never had clear steps to reproduce. Does anyone have updated info on whether it is fixed or steps to reproduce it? If not provided within ~3 months, this issue will be closed.

Thanks!

Okay, I'm running into this problem with media.

Some specs:

• No redis/memcache/any in-memory database system
• Do have PHP APCu caching
• Transaction isolation level: REPEATABLE-READ

When a user added 8 media items, only 3 of them experienced this bug.

And even after clearing the cache, this problem remained.

We have encountered this issue in at least two client projects. While investigating the issue, the issue can be fixed temporarily by clearing caches and this allows the content to be saved again. But after the content is saved again, the second revision is visible again and it blocks saving the content a second time with the same error related to untranslated fields not being editable.

More details re: media revisions numbers not being accurate.

(Note: I'm using Drupal 10.3.)

So, what's happening is that when a media item is loaded, it's not loading the latest revision.

E.g. When there are two revisions 454 and 455, for some reason the system is loading 454 by default (instead of 455).

--

Also, this code makes the system act really strange. Specifically, after running this code, the newest revision ID is not displayed on the new media revision UI (mentioned here: https://www.drupal.org/node/3366630).

      $mediaStorage = $this->entityTypeManager()->getStorage('media');
      $lastestId = $mediaStorage->getLatestRevisionId($media->id());
      $lastestMedia = $mediaStorage->loadRevision($lastestId);

      $media->set(HrConstants::documentIsInitializedField, $lastestMedia->get(HrConstants::documentIsInitializedField)->value);
      $media->setNewRevision(TRUE);
      $media->setRevisionLogMessage('Resave to avoid revision number being incorrect.');
      $media->save();

Can issue summary be updated with steps to reproduce if still an issue.

This is an issue as reported by 2 of our clients. I haven't been able to determine the exact process / steps to reproduce based on the information received. I'll update here once I'm able to reproduce.

Going to close out but if anyone has concrete steps to reproduce we can re-open.

I know this has closed but yet again - here I report that this happened again with a couple client websites. Trying to track down a way to reliably reproduce but the bug is there. Multiple concurrent current revisions creates issues in content management.