Switch to a null backend for all caches for running the database updates

So if we do this I think we should only clear out the cache bins (this logic copied from drupal_flush_all_caches() rather than doing a full rebuild to minimise the code path.

  foreach (Cache::getBins() as $service_id => $cache_backend) {
    $cache_backend->deleteAll();
  }

Another thought is that we should not be write or reading anything from caches until update.php is done with.

Also putting it in the batch is too late - #3052971: Notice: Undefined index: #include_fallback in Drupal\Core\Render\Element\StatusMessages::generatePlaceholder() occurs when the user visits update.php

I think whatever we do should potentially be in \Drupal\Core\Update\UpdateServiceProvider

There's an issue that aims to use memory cache backends for the installer, could we do the same for update? However, just like in the installer is that at the end, we do want to clear the real caches.

@Berdir +1 to the memory cache idea. At least means we don't spend unnecessary resources working things out twice.

Let's see what breaks - gonna add some proper testing to ensure the cache is cleared by an update.

The change to core/tests/Drupal/FunctionalTests/Update/UpdatePathTestBase.php is no longer necessary now we're passing deletes on to the real cache backend.

@catch asked for some comments about why we have the changes to the cache classes.

1) s/serialised/serialized
Content style guide specifies American spelling, and it's used with American spelling on core.

diff --git a/core/lib/Drupal/Core/Cache/MemoryCache/MemoryCache.php b/core/lib/Drupal/Core/Cache/MemoryCache/MemoryCache.php
index 3271108211..c6fa20ba98 100644
--- a/core/lib/Drupal/Core/Cache/MemoryCache/MemoryCache.php
+++ b/core/lib/Drupal/Core/Cache/MemoryCache/MemoryCache.php
@@ -8,40 +8,29 @@
 /**
  * Defines a memory cache implementation.
  *
- * Stores cache items in memory using a PHP array.
+ * Stores cache items in memory using a PHP array. Cache data is not serialised
+ * thereby returning the same object as was cached.

2) same for s/minimise/minimize
3) same for s/whilst/while

Indeed - thanks @oknate!

Resolved the @todo and added a change record.

Rerolled now that #2863986: Allow updating modules with new service dependencies has landed.

Just nits. Looks really good to me now otherwise.

1. +++ b/core/lib/Drupal/Core/Update/UpdateBackend.php
   @@ -0,0 +1,50 @@
   + * uses anything cached prior to running updates.
   

   using

2. +++ b/core/lib/Drupal/Core/Update/UpdateCacheBackendFactory.php
   @@ -0,0 +1,35 @@
   + * Decorates the real cache factory to use the special UpdateBackend.
   

   This should probably be either actual English or the fully qualified class name.

@catch thanks for the review. I re-read all the things and found some missing properties and copy pasta. I decided to drop the "real" from the names of things because it's not helpful and replaced with "regular runtime" which I think is more indicative of what I meant by "real".

This looks good to me. We are already using this patch for our Thunder 2 -> 3 update path and it works very well.

Committed c22202e and pushed to 8.8.x. Thanks!

I think we should consider backporting to this to 8.7.x.

• It fixes problems with updating from contrib media_entity to core media - which is something we want people to do.
• It fixes problems caused by extension serialisation that have mostly been fixed but can still occur under some circumstances.

Also whilst this change is big

• it is to the update path caching and basically makes everyones updates behave in the way we actually test them.
• it is only to the update system which doesn't affect the regular run-time of a site.

Unfortunately we need to revert this as it is causing random fails for SQLite. Not sure why yet. See https://www.drupal.org/pift-ci-job/1353542 for an example fail.

So this patch fixes the random fail. I've not worked out why it's happening yet.

Okay worked this out :( it's because system_update_8013() does not account for the container rebuild :( :( :(

This happens for all db types it just happens that SQLite does updates fast enough sometimes for system_update_8013() and system_update_8200() to run in the same batch.

Whilst the patch attached fixes the problem I'm not 100% sure it is the correct solution. The reason nothing goes wrong in HEAD is that none of the protected properties on the stale config factory are re-used during the save after the container rebuild. I think the correct solution might be do use a static property in

So here's the fix I think we should do. We need to make the UpdateBackend caches survive a container rebuild so they behave more like a consistent cache like DatabaseBackend. Therefore we need to use statics.

All the interdiffs are back to #23 - I include a simple fail patch that fails with a very small addition to #23 to show the problem. This fails regardless of DB backend.

I wonder if I should put the static stuff into it's own backend because I suspect it would safer to use in #2488350: Switch to a memory cache backend during installation too. Install has plenty of container rebuilds going on.

This seems like a problem with the contact test to me - i.e. the test runner is using a stale version of the container.
Same problem as in #2066993: Use \Drupal consistently in tests. See diff for a suggestion.

Discuss a bit more with @catch. We ruled out #32 because statics have their own level of problems and while it does it the UpdateBackend more like the DatabaseBackend @catch favoured another solution. We can extend the NullBackend instead and not actually cache anything!

I include a test patch which adds test code to system_udpate_8013() to prove we have it fixed.
The "real" patch here fixes system_udpate_8013() so that core sets a good example for contrib and custom to follow.

Now we're extending from NullBackend there's no need to fix the MemoryBackend or MemoryCache classes.

The improvements to MemoryBackend and MemoryCache can be a part of #2488350: Switch to a memory cache backend during installation - which is where they came from originally.

We need a title and an IS update here since we are no longer switching to the memory backend.

@chr.fritsch good point.

Looks good. We are already using this patch in Thunder for a while.

+++ b/core/lib/Drupal/Core/Update/UpdateBackend.php
@@ -0,0 +1,54 @@
+ * Defines a cache backend for use during updating Drupal.

*during Drupal database updates

(fixable on commit).

1. +++ b/core/lib/Drupal/Core/Update/UpdateBackend.php
   @@ -0,0 +1,54 @@
   + * Passes on deletes to another backend while extending the NullBackend to avoid
   + * using anything cached prior to running updates.
   

   Woah! Super interesting 🤩

2. +++ b/core/lib/Drupal/Core/Update/UpdateCacheBackendFactory.php
   @@ -0,0 +1,51 @@
   + * Cache factory implementation for updating Drupal.
   

   🤓 Nit: "to use when updating Drupal" would be more accurate I think?

3. The change record's title and text still are talking about MemoryBackend, but this is now using a subclassed NullBackend.

Here's fixes for #43.2 and #42 - going to update CR now..

Committed 80a307d and pushed to 8.8.x. Thanks!

I came across this: #2981353: The "media" entity type does not exist which led to this core issue. This seems to state that this fix was committed to 8.8.x 4 months ago yet I am running 8.8.1 which is only 1 month old.. and i am still getting this error when i try to do a db update.

i found another post suggesting to enable the (core) Media module - and this solved the issue.

Published the CR