ViewsEntitySchemaSubscriber access undefined property of View

+++ b/core/modules/views/src/Entity/View.php
@@ -114,6 +114,18 @@ class View extends ConfigEntityBase implements ViewEntityInterface {
+  /**
+   * Runtime property used for config updates.
+   *
+   * phpcs:disable Drupal.Classes.PropertyDeclaration
+   * @todo Remove PHPCS override https://www.drupal.org/i/2052421.
+   *
+   * @var bool|null
+   *
+   * @see \Drupal\views\EventSubscriber\ViewsEntitySchemaSubscriber::onEntityTypeUpdate()
+   */
+  protected ?bool $_updated;

this is a pretty weird one.

Ironically, this property was created 6 years *after* the meta issue that's supposed to remove them which wasn't updated since 2016, which also makes sense as renaming them is an API change in many cases. And it actually explicitly uses get/set, wondering if it wasn't clear that this just sets a property with that name.

This is clearly an internal property that is just used in that single subscriber. Could we rewrite it to e.g. store the list of ids that should be resaved in a protected property of that subscriber:

$this->viewsToResave[$view->id] = TRUE/$view;

+++ b/core/modules/views/src/EventSubscriber/ViewsEntitySchemaSubscriber.php
@@ -208,17 +215,12 @@ public function onEntityTypeUpdate(EntityTypeInterface $entity_type, EntityTypeI
+    $this->viewsToSave = array_filter($this->viewsToSave, function (ViewEntityInterface $view) use ($entity_type) {
       try {
         // All changes done to the views here can be trusted and this might be
         // called during updates, when it is not safe to rely on configuration
         // containing valid schema. Trust the data and disable schema validation
         // and casting.
-        $view->set('_updated', NULL);
         $view->trustData()->save();
       }
       catch (\Exception $e) {
@@ -230,7 +232,8 @@ public function onEntityTypeUpdate(EntityTypeInterface $entity_type, EntityTypeI

@@ -230,7 +232,8 @@ public function onEntityTypeUpdate(EntityTypeInterface $entity_type, EntityTypeI
           '%entity_type_id' => $entity_type->id(),
         ]);
       }
-    }
+      return FALSE;
+    });

that's a very creative use case for array_filter() :) should we just make this a plain old foreach and reset viewstoSave at the end?

9.5 looks like an unrelated random fail:

1) Drupal\Tests\ckeditor5\FunctionalJavascript\MediaLibraryTest::testButton
Failed asserting that a NULL is not empty.

/var/www/html/vendor/phpunit/phpunit/src/Framework/Constraint/Constraint.php:119
/var/www/html/vendor/phpunit/phpunit/src/Framework/Constraint/LogicalNot.php:115
/var/www/html/core/modules/ckeditor5/tests/src/FunctionalJavascript/MediaLibraryTest.php:174
/var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:703

this is just one of what's going to be many necessary fixes, but I think this makes sense.

Disclaimer: I didn't write any code, but the patch is directly based on my suggestion in #4, so maybe someone else wants to +1 this.

diff --git a/core/modules/views/src/EventSubscriber/ViewsEntitySchemaSubscriber.php b/core/modules/views/src/EventSubscriber/ViewsEntitySchemaSubscriber.php
index 9c008ef728..f8f5ea845b 100644
--- a/core/modules/views/src/EventSubscriber/ViewsEntitySchemaSubscriber.php
+++ b/core/modules/views/src/EventSubscriber/ViewsEntitySchemaSubscriber.php
@@ -84,7 +84,7 @@ class ViewsEntitySchemaSubscriber implements EntityTypeListenerInterface, EventS
   protected $logger;
 
   /**
-   * Indexed array by view name that require to save.
+   * Array of views that need to be saved, indexed by view name.
    *
    * @var \Drupal\views\ViewEntityInterface[]
    */

Made this change on commit. Everything else looks great so committed/pushed to 10.1.x and cherry-picked back to 9.5.x