Out of memory error with metatag_view submodule and Search API view

I get the same error on two different D9.3 websites (both migrated from D7). In my case, though, the error occurs when the metatag_views submodule is enabled, and I click on the preview button in any view. The preview does not work and I get the error:

2021/12/23 16:48:03 [error] 1494#1494: *20076595 FastCGI sent in stderr: "PHP message: Error: Call to a member function getCurrentPage() on null in /var/www/supersyntages.gr/web/core/modules/views/src/Plugin/views/cache/CachePluginBase.php on line 220 #0 /var/www/supersyntages.gr/web/modules/contrib/metatag/metatag_views/src/MetatagViewsCacheWrapper.php(92): Drupal\views\Plugin\views\cache\CachePluginBase->generateResultsKey()
#1 /var/www/supersyntages.gr/web/core/modules/views/src/ViewExecutable.php(1419): Drupal\metatag_views\MetatagViewsCacheWrapper->cacheGet('results')
#2 /var/www/supersyntages.gr/web/core/modules/views/src/ViewExecutable.php(1454): Drupal\views\ViewExecutable->execute(NULL)
#3 /var/www/supersyntages.gr/web/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php(2460): Drupal\views\ViewExecutable->render()
#4 /var/www/supersyntages.gr/web/core/modules/views/src/ViewExecutable.php(1662): Drupal\views\Plugin\views\display\DisplayPluginBase->preview()
#5 /var/www/supersyntages.gr/web/core/modules/views_ui/src/ViewU...PHP message: PHP Fatal error:  Uncaught Error: Call to a member function get() on null in /var/www/supersyntages.gr/web/core/lib/Drupal/Core/Session/SessionHandler.php:79
Stack trace:
#0 /var/www/supersyntages.gr/web/core/lib/Drupal/Core/Session/WriteSafeSessionHandler.php(95): Drupal\Core\Session\SessionHandler->write('gpAZowrZD4dgvtd...', '_sf2_attributes...')
#1 /var/www/supersyntages.gr/vendor/symfony/http-foundation/Session/Storage/Proxy/SessionHandlerProxy.php(71): Drupal\Core\Session\WriteSafeSessionHandler->write('gpAZowrZD4dgvtd...', '_sf2_attributes...')
#2 [internal function]: Symfony\Component\HttpFoundation\Session\Storage\Proxy\SessionHandlerProxy->write('gpAZowrZD4dgvtd...', '_sf2_attributes...')
#3 [internal function]: session_write_close()
#4 {main}
  thrown in /var/www/supersyntages.gr/web/core/lib/Drupal/Core/Session/SessionHandler.php on line 79" while reading response header from upstream, client: 79.130.XXX

Note in my case, the view (page or block) itself does work. Only the preview functionality breaks.

Might this be related to #2952229?

Please note, that by downgrading to 1.16 solved the problem for me:
composer require 'drupal/metatag:1.16'
drush cr.
Now the preview in views works as before.

@oxy86 , you could try the patch from https://www.drupal.org/project/metatag/issues/3255547 , it should solve the problem with preview

Thanks, Eugene. I will test your patch from #3255547 and report results in that issue. Damien, sorry for polluting this issue with extra noise :)

I am having this issue with Metatag v1.18 + Search API views as well on two different sites. In one case the initial search view loads but will run out of memory for any query (regardless of available memory) and in the other case the initial search view runs out of memory as well. #3255547: Metatag Views breaks Views previews and some Views pages does indeed resolve the preview issue but does not resolve the issue with the regular view.

Reverting to Metatag v1.16 is a workaround and I'll try to follow up with some additional research.

\Drupal\metatag_views\MetatagViewsCacheWrapper::cacheGet at line 92 seems to get stuck in an infinite loop when I enter a search term in the view. This was introduced in #2952229: Allow Views meta tags to "Use replacement tokens from the first row" (D8) and reminded me that I actually ran in to this issue a while back when I tried to use the patch on that issue. I ultimately could not figure out what was causing it so had to back out the patch (and, of course, forget to follow up and leave feedback on that issue!).

Further to #9 -- the loop happens because getting the results from the cache unserializes and re-executes the view (see core/modules/views/src/ViewExecutable.php#L2539).

However, if I comment out all of \Drupal\metatag_views\MetatagViewsCacheWrapper::cacheGet then \Drupal\views\Plugin\views\cache\CachePluginBase::cacheGet still causing an out of memory error so the issue doesn't seem to be with \Drupal\metatag_views\MetatagViewsCacheWrapper::cacheGet itself. Maybe something to do with how the cache data is saved?

The bit above isn’t relevant. Just commenting that method out has other Side effects. See further comments.

Further to #10 -- If I comment out core/modules/views/src/ViewExecutable.php#L2540 (the view re-execution) everything appears to work fine -- the search takes place, the results are correct, and the views data and results are cached and retrievable. I backtracked that behavior a bit because the re-execution seemed odd to me but it goes back six years to #2252763: Views exposed filter form causes enormous form state cache entries (see comment #46). The comment there didn't help me fully understand the need but presumably this would be an issue elsewhere in core if that core change was incorrect in some way. So that seems like a dead end.

One thing I eventually noticed testing this is that the generated results cache key was always the same regardless of the fulltext search term I used. In my case the search view is configured to use tag-based caching. If I disable that caching everything works as expected. So it seems fair to say that the actual initial issue for me is just that I had tag-based caching enabled for the search view when I should not have (and the problem is just exposed by Metatags v1.18).

@zcht says in the initial issue description that they are seeing this issue while not using tag caching. @zcht could you verify that is the case (i.e. that your view display advanced config has "None" for the "Caching" setting)?

I discovered that despite having the caching for my search view set to "Tag based" nothing was actually being cached because of the fulltext search filter (I'm not sure where or how this actually gets cut off but cache-related breakpoints were not hit when I was testing this). I also noticed that the Search API module provides a "Search API (tag-based)" view caching method that does seem to work fine with Metatag v1.16.

But I do still find myself back to out of memory errors if I use Metatag v1.18 in conjunction with the Search API provided tag-based caching so it seems there is still some incompatibility issue when \Drupal\metatag_views\MetatagViewsCacheWrapper wraps \Drupal\search_api\Plugin\views\cache\SearchApiTagCache and overrides its custom ::cacheSet and ::cacheGet methods (in \Drupal\search_api\Plugin\views\cache\SearchApiCachePluginTrait).

So this is bizarre -- I created an environment to confirm this issue is not specific to anything about my (or the original reporter's) setup other than the module combination and configurations: https://github.com/CascadePublicMedia/metatag-3245876. Initially it seemed to confirm what I found in previous comments but when I start from scratch the View that I had configured to use Search API's provided tag caching is reset to uncached and the OOM issue persists. When I change it to Search API's tag caching things actually work normally again (i.e., the exact opposite of the result I get and can still reproduce in #12).

Same issue here. I've got a search api view which go into an infinite loop.
Trying #9 by swapping this block from \Drupal\metatag_views\MetatagViewsCacheWrapper::cacheGet

 if ($type === self::RESULTS) {
      $cutoff = $this->plugin->cacheExpire($type);
      // Values to set: $view->result, $view->total_rows, $view->execute_time,
      // $view->current_page and pass row tokens to metatag display extender.
      if ($cache = \Drupal::cache($this->plugin->resultsBin)->get($this->plugin->generateResultsKey())) {
        if (!$cutoff || $cache->created > $cutoff) {
          $view = $this->plugin->view;
          $view->result = $cache->data['result'];
          // Load entities for each result.
          $view->query->loadEntities($view->result);
          $view->total_rows = $cache->data['total_rows'];
          $view->setCurrentPage($cache->data['current_page'], TRUE);
          $view->execute_time = 0;
          $extenders = $view->getDisplay()->getExtenders();
          if (isset($extenders['metatag_display_extender'])) {
            $extenders['metatag_display_extender']->setFirstRowTokens($cache->data['first_row_tokens']);
          }
          return TRUE;
        }
      }
      return FALSE;
    }

Edit : The views has the same issue. It run normally only if I disabled the cache on the views (currently configured with the search API tag).

Same issue here after updating from 8.x-1.16 to 8.x-1.18 with Search API and SolR.
Reverting back 1.16 fixes the issue.

I realised my memory leak issue was caused by metatag after profiling the page, here is a screenshot of the stack in case it is useful :

That is very useful, thank you.

Is it weird to anyone else that cacheGet() is being loaded twice in the same execution process?

@DamienMcKenna see #11 above -- it seems to get triggered over and over because when the cached view data is being unserialized it re-executes the view (checking the cache again in the process).

I have the same problem. I use it with the Search API. The rollback of the metatag module to version 8.x-1.16 helped

I found that Drupal\search_api\Plugin\views\row\SearchApiRow during prerender adds entity to each result row inside keys _object and _item, and adds view to this node as a property.

$entity->view = $this->view;

And while MetatagViewsCacheWrapper saves cache on postrender, those entities objects with views inside go to the cache and obviously cause infinite loop on restoring from cache.

$plugin->prepareViewResult($view->result) in the MetatagViewsCacheWrapper::doDeferredCacheSet() only cleans up _entity key in the results, but entity still remains in _object, _item and _relashionship_objects.

I don't know the right way to solve this yet.

I, too, have a view that pulls from a Solr index. I, too, am getting out-of-memory errors when trying to load a page which includes this view.

The out-of-memory errors began when I upgraded from Metatag 8.x-1.16 to 8.x-1.18.

Rolling back to 8.x-1.16 fixes the issue.

Should we disable the cache as a temporary work-around? It's a little harsh, but it would at least stop this part of the problem.

Maybe. But #21 sounds promising for getting closer to a solution here. With 8.x-1.19 just going out we may as well keep working at this a bit, no?

I ran into this issue yesterday after updating to 1.18. Whenever anyone hit the adoption page -- a big SAPI views page -- it would go into a recursive loop, OOM, and then k8s would kill the container. Causing an outage.

You can see in the screenshot it bouncing between the session handler, memcache, and metatag repeatedly:

The only hint of this error was when we ran the site locally and the following log messages were written:

[07-Jan-2022 14:06:57 America/Chicago] PHP Fatal error:  Allowed memory size of 335544320 bytes exhausted (tried to allocate 20480 bytes) in /var/www/html/modules/contrib/memcache/src/Driver/MemcachedDriver.php on line 72
[07-Jan-2022 14:06:57 America/Chicago] PHP Fatal error:  Allowed memory size of 335544320 bytes exhausted (tried to allocate 65536 bytes) in /var/www/html/core/lib/Drupal/Core/Database/Query/Merge.php on line 46
[07-Jan-2022 14:08:45 America/Chicago] PHP Fatal error:  Allowed memory size of 335544320 bytes exhausted (tried to allocate 65536 bytes) in /var/www/html/core/includes/errors.inc on line 60

Rolling back to 1.16.0 fixed the issue.

The first step might be to add search_api as a test dependency?

Has anyone confirmed the smallest configuration required to trigger this problem?

To make this issue easier to work with, I'm moving the huge backtrace from comment #2 into a .txt attachment...

Re: #26 -- if you have Lando handy this repo is just Metatags + Search API + default database search configuration: https://github.com/CascadePublicMedia/metatag-3245876

p.s. Sounds like 8.x-1.6 is the last version without this bug. Moving to 1.x-dev for now since that seems more appropriate. Added rolling back to that as a temporary work-around under proposed resolution.

I had this issue after updating to 1.18, and can confirm it seems to have been resolved by updating to 1.19

It seems there is some confusion (#30, #31) between this issue and #3255547: Metatag Views breaks Views previews and some Views pages as the original description for this issue is actually part of #3255547: Metatag Views breaks Views previews and some Views pages. Note that what is being discussed here is out-of-memory issues in relation to Metatag v1.18+ and (at least) Search API views and cache and that is still an issue with the latest version of Metatag.

Configuration from https://github.com/CascadePublicMedia/metatag-3245876 works for me without errors now if metatag updated to 1.19 . But if I enable memcache module, turn on view's caching and check option "Use replacement tokens from the first row" in the Search API view metatag configuration I get "Out of memory ..." error.
I thought, although we got error after implementing new funcionallity in metatag, the root of the problem might be outside the matatag module.

@wells I'm not confused: I had the out of memory issue on Metatag 1.18 and it's been resolved by upgrading to 1.19. I had it on a SAPI view with the cacheing disabled (as it used Facets), so it may still be an issue if the view is cached.

Ah, ok. Thanks for testing, @Eugene Bocharov.

That may explain the same error but different repro steps I got with that repo despite the same circumstances. I think I was experiencing both issues on at least one of my sites but maybe only one issue on another. I will perform some new testing with the 8.x-1.19 release and try to clear this up further.

Also worth noting that multiple people here report this issue when using Memcache but at least one (#16) experiences it with Redis as well. Maybe that doesn’t amount to much but I figured it’s worth pointing out given the findings in #33.

@MrDaleSmith thanks for clarifying. I think #3255547: Metatag Views breaks Views previews and some Views pages fixed more than I realized and what remains does appear to be specifically related to caching.

I think the issue could be resolved on the search_api side. I've created an issue and proposed the patch there https://www.drupal.org/project/search_api/issues/3258375

Having the same issue with a Redis cache system in use (D9.3, Metatag 1.19)
Using patches from https://www.drupal.org/project/search_api/issues/3258375 and https://www.drupal.org/project/metatag/issues/3258346 fixed it. Thanks Eugene.

Separate issues were posted in Facets & Metatag modules that identifies the custom cache system as causing a problem: #3258080: Facets disappear on refresh and #3261473: Views cache wrapper overrides other modules cache logic

Can also confirm the patch from https://www.drupal.org/project/search_api/issues/3258375 worked for us.