error=[37]ITEM TOO BIG, script tried to access a property on an incomplete object, and Call to a member function set() on null after 8.x-2.6 upgrade

+1

Reporting similar issue, with certain blocks generating MemcachedDriver::set() error ... ITEM TOO BIG.
No other obvious related errors.
The content loads initially but a page refresh returns empty block.
Downgrade to 8.x-2.5 and the issue goes away.

Same here, for example when listing users.

Had a similar issue with a cacheable response from a rest resource. I didn't try downgrading, but instead moved the dynamic page cache into redis for now.

Speculating that 📌 Memcache performance issue from big (i.e. chunked) cache items Fixed might have introduced a regression?

I looked at the commits and found this:
https://git.drupalcode.org/project/memcache/-/commit/cb11e23520860ee6a46...

  private function combineItems(array $items) {
-    return unserialize(implode(array_column($items, 'data')));
+    return unserialize(implode(array_column($items, 'data')), ['allowed_classes' => FALSE]);
  }

Maybe this may cause missing or incomplete classes?

Thanks @jan! For me it doesn't break now, when listing users and in other places where I was having memcache's WSOD.

I'm sending a simple patch just to keep speed up people who would like to test it also.

jan kellermann → changed the visibility of the branch 8.x-2.x to hidden.

Created fork and MR.

Thanks @jan! Patch #7 with this fix works for me.
I also had related 500 PHP errors when visiting views page:

TypeError: htmlspecialchars(): Argument #1 ($string) must be of type string, __PHP_Incomplete_Class given in htmlspecialchars() (line 437 of /var/www/cmds/docroot/core/lib/Drupal/Component/Utility/Html.php).
#0 /var/www/cmds/docroot/core/lib/Drupal/Component/Utility/Html.php(437): htmlspecialchars()
#1 /var/www/cmds/docroot/core/lib/Drupal/Component/Render/FormattableMarkup.php(268): Drupal\Component\Utility\Html::escape()
#2 /var/www/cmds/docroot/core/lib/Drupal/Component/Render/FormattableMarkup.php(217): Drupal\Component\Render\FormattableMarkup::placeholderEscape()
#3 /var/www/cmds/docroot/core/lib/Drupal/Core/StringTranslation/TranslatableMarkup.php(195): Drupal\Component\Render\FormattableMarkup::placeholderFormat()
#4 /var/www/cmds/docroot/core/lib/Drupal/Component/Utility/ToStringTrait.php(15): Drupal\Core\StringTranslation\TranslatableMarkup->render()
#5 /var/www/cmds/docroot/core/modules/views_ui/src/ViewEditForm.php(1148): Drupal\Core\StringTranslation\TranslatableMarkup->__toString()
#6 /var/www/cmds/docroot/core/modules/views_ui/src/ViewEditForm.php(622): Drupal\views_ui\ViewEditForm->getFormBucket()

And this one:

Error: Object of class __PHP_Incomplete_Class could not be converted to string in Drupal\views\Plugin\views\relationship\RelationshipPluginBase->defineOptions() (line 97 of /var/www/cmds/docroot/core/modules/views/src/Plugin/views/relationship/RelationshipPluginBase.php)
#0 /var/www/cmds/docroot/core/modules/views/src/Plugin/views/PluginBase.php(143): Drupal\views\Plugin\views\relationship\RelationshipPluginBase->defineOptions()
#1 /var/www/cmds/docroot/core/modules/views/src/Plugin/views/HandlerBase.php(109): Drupal\views\Plugin\views\PluginBase->init()
#2 /var/www/cmds/docroot/core/modules/views/src/Plugin/views/relationship/RelationshipPluginBase.php(67): Drupal\views\Plugin\views\HandlerBase->init()

This killed a few of our sites, patch in #7 works

This affected our sites as well. Patch #7 fixes it.

Bah. linting is the bane of things. I've reverted it and committed. Will get a release out shortly.

Automatically closed - issue fixed for 2 weeks with no activity.