RuntimeException while trying to render item

I'm getting the same thing after simply editing and saving a node:

RuntimeException while trying to render item entity:node/3742:en with view mode search_index for search index Social all: Failed to start the session because headers have already been sent by /app/vendor/symfony/http-foundation/Response.php at line 384. in Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() (line 152 of /app/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php).

We experienced the same exception in combination with Layout Builder and direct indexing. The fix was to disable route enhancement done by the layout_builder.tempstore.route_enhancer service during indexing.

So I decorated the layout_builder.tempstore.route_enhancer service and added a disable() and enable() method. These are invoked from and event subscriber that listens for the SearchApiEvents::INDEXING_ITEMS and SearchApiEvents::ITEMS_INDEXED events.

If disable the decorated enhancer simply returns the defaults:

public function enhance(array $defaults, Request $request) {
  if ($this->disabled) {
    return $defaults;
  }

  return $this->inner->enhance($defaults, $request);
}

I am getting the same issue when saving Commerce Products, core and module also up to date.

I would like to note that when this is happening it seems like it might be preventing commits to solr.

I was also experiencing this issue: https://www.drupal.org/project/search_api_solr/issues/3176015 , pretty much exactly as described the comment #17, and had to reload the core to see changes in solr. I was also getting the errors in this issue.

As a test I setup the index field for the fulltext rendered item to not include the rendered item for my product types. Not really a solution, I know, but just wanted to see if it also was causing the other issue. After I did that I didn't get this error and the changes to the solr index were getting committed with no issues.

I am still getting this error when I set the fulltext rendered_items field to index the product rendered item though (using the default view mode).

I had this exact error when editing/saving a node, which caused it to not be indexed. Tried everything: removing fields from the index, uninstalling modules, disabling all processors etc. The only "fix" was to disable the "Index items immediately" option and have it index on cron run instead. We use Ultimate Cron to set the Search API cron jobs to run every 5 minutes.

We also had a problem when using "Index items immediately" option.

We have one content type with a call to a view in templeate file as content. When indexing "full" node for "rendered_item" then the RuntimeException occour.

Perhaps it occurs because of the RedirectResponse when saving a node? That would explain why the RuntimeException mentions "headers already sent". So indexing full node would need to create e new session which could not because of Redirect already sent.

We discovered that with Drupal core 9.4.9 it works, but after update to 9.5.3 the RuntimeException is thrown. We used in both cases search_api version: 8.x-1.28.

#5 fixed the issue for us as well.

We have Drupal 9.5.5 with an Apache Solr server and also got this error when saving a node. Disabling "Index items immediately" in the search index config fixed the error and successfully updated the search index on the next cron run.

Same issue, using Layout Paragraphs so essentially Layout Builder.

I started getting this Runtime Exception after upgrading Drupal 9 core and Search API module recently.

It's triggered when Search API attempts to render the field that contains "rendered item".
File: search_api/src/Plugin/search_api/processor/RenderedItem.php
Method: function addFieldValues()
Line 292: $value = (string) $this->getRenderer()->renderPlain($build);

It appears that issue was introduced by a change in Drupal core:

1. Drupal core commit - see line 2234 in file core/modules/views/src/Plugin/views/display/DisplayPluginBase.php
2. Related Drupal core issue: Views pager is using exposed_raw_input instead of exposed_input

Above commit introduced call to $view->getExposedInput() which in turn calls $session->get('views') (see web/core/modules/views/src/ViewExecutable.php). I confirmed that by commenting out $session->get('views') calls within getExposedInput() method I can get rid of the Runtime Exception.

In order to reproduce the issue you need the following:

1. Drupal 9 version 9.5.4 or higher
2. Search API module configured to index content immediately upon save
3. Search API module configured to index rendered entity
4. Apache Solr configured as a search backend
5. Content type with one of the following
   1. Regular page display with EVA (Entity Views Attachment) field
   2. Layout managed by the Layout Builder that includes views block or EVA field

Most of the times above configuration will cause the Runtime Exception but I did notice few instances where that didn't happen. I'm not sure exactly why. My guess is that views configuration in those cases is such that rendering of the view block or EVA field skips the block of code that is responsible for throwing the exception.

Same change was committed to Drupal 10 so I'm assuming this issue will be present in Drupal 10 as well but I didn't verify that personally.

I'm leaving it to module maintainers to decide whether this issue can be fixed within Search API module or it needs to be moved to Drupal core issue queue.

Disabling "Index items immediately" option as described in #5 worked for us in a project where this happened as well.

Does this still occur with the latest release of the Search API? I think we fixed this in #3252430: Catch exception on indexing using Search API and keep indexation continuing. (Well, at least we’re catching the exception – nothing really we can do about its cause, as that is never in our code and also different from site to site. Basic problem is: Almost anything can happen during rendering, and some parts can implicitly rely on information that just isn’t there when indexing items.)

Yes, I can confirm that this error still frequently occurs even with Search API 1.29. In fact, it is currently one of the most frequently occurring errors in the recent log messages on our site at the moment. For us, we started seeing this error on April 28th and it's been frequently occurring ever since then.

I’m not talking about the log messages, I’m talking about this actually bringing the site (and indexing) to a halt.
As said above, we cannot do anything about the exception itself since that’s caused by some other module, most likely because we’re rendering the entity in an unexpected context.

For instance, see Matthijs’ explanation in #3: he identified the source of the exception in his case and then applied a workaround. Depending on the exact exception and cause, reporting an issue for the module in question might also make sense. In general, I do think that rendering an entity should work regardless of context – maybe not exactly the same in every context, but at least there shouldn’t be fatal errors.
But, as said above, the root cause will be different for everyone, there’s really not much we can do in this issue except exchange battle stories in the hope that it helps someone with exactly the same problem.

And, of course, if someone finds anything we can do that prevents some of these problems in a general manner, that’s also worth discussing.

But so far the only thing that works for a lot of people seems to be to disable “Index items immediately”. So maybe try using that?

Based on my own comment, I guess “Avtive” is the most fitting status.

Looks like we are experiencing the same issue. We are using Drupal 9.5.8 with search_api 8.x-1.29. When immediate indexing is enabled and we attempt to save a node we get the following error message:

RuntimeException while trying to render item entity:node/475:en with view mode full for search index X: Failed to start the session because headers have already been sent by "/var/www/vendor/symfony/http-foundation/Response.php" at line 368. in Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() (line 152 of /var/www/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php).

Indexing into Solr fails completely as far as I can see. I suspect there is an issue with the markup in our layout builder block, a hook or twig file, etc but it has been difficult to track down. If I change the view mode to anything other than full it indexes into Solr as expected. Obviously the page is broken without the proper markup in place but at least we know the issue is indeed related to the full mode while using layout builder plus immediate indexing.

It is a pretty significant issue for our publishing group but we are currently working around it by disabling "Index items immediately" and using cron to trigger the indexing.

I have been able to confirm that adding a Drupal view to my layout builder page causes the above error. If I just have blocks or other content indexing works as expected.

See also #3317397: Rendered item is not indexed in groups content using layout builder for an issue that might be related. Maybe in some of the cases described here the issue is that we set a dummy account (without user ID) as the current user?

Seeing this on Drupal 9.5.9

Are there any work arounds known? This of course is showing up on launch day...

Workaround in #5 fixed the immediate problem

I just found another cause for this issue: if your content to be indexed contains a view element, \Drupal\views\ViewExecutable::getExposedInput() will try to start a session (and thus send headers) to restore the stored exposed filters.

I refactored my workaround described in #3274158-3: RuntimeException while trying to render item to fix this and ended up with a pre render callback to set the exposed filters:

public static function preRenderElement(array $element): array {
  if (!static::getSearchApiStatus()->isIndexing()) {
    return $element;
  }

  // Initialize the exposed filters so Views won't start the session.
  // @see \Drupal\views\ViewExecutable::getExposedInput()
  /** @var \Drupal\views\ViewExecutable $view */
  $view = $element['#view'];
  $view->initDisplay();
  $view->setExposedInput(['' => '']);

  // Disable render caching.
  $element['#cache']['max-age'] = 0;

  return $element;
}

Here is the related core issue

I confirm this is still happening on Drupal core 9.5.10 and Search API 8.x-1.29. In my case, it happens when I have index item automatically, and I save a layout builder page/node.

Also, it only happens when I have the System > Breadcrumbs block. When I remove this block and keep only the "Basic Blocks" it works fine.

@Matthijs regarding your workaround in #15, what is it that you've added this prerender callback to?

@Jaypan I guess you mean #19, I added it to the view render element using hook_element_info_alter().

/**
 * Implements hook_element_info_alter().
 */
function my_module_element_info_alter(array &$info): void {
  array_unshift($info['view']['#pre_render'], [ViewElement::class, 'preRenderElement']);
}

I did mean #19, and thank you. Can you please show getSearchApiStatus()->isIndexing() as well? Where is this coming from? I searched Search API and did not find these methods.

@Jaypan

The work around I came up with involve disabling automatic indexing and hooks:

use Drupal\Core\Entity\EntityInterface;
use Drupal\search_api\Entity\Index;

/**
 * Implements hook_ENTITY_TYPE_insert().
 */
function my_module_node_insert(EntityInterface $node) {
    __my_module_index_node($node);
}

/**
 * Implements hook_ENTITY_TYPE_update().
 */
function my_module_node_update(EntityInterface $node) {
    __my_module_index_node($node);
}

function __my_module_index_node(EntityInterface $node) {
  if ($node->bundle() == 'targted_bundle') {
    $index = Index::load('targted_index');
    if ($index) {
        $language = \Drupal::languageManager()->getCurrentLanguage()->getId();
        $item_id = 'entity:node/' . $node->id() . ':' . $language;
        $items = [$item_id => $node->getTypedData()];
        $index->indexSpecificItems($items);
    }
  }
}

Would like how @Matthijs implemented that getSearchApiStatus()->isIndexing().

But it is not just the exposed filters that trigger the issue,
flag_views_query_substitutions() and presumably other contributed modules also trigger it.

You can find my complete code attached. Please note that I extracted this from a project without testing.

I am getting the error on Drupal Version 10.1.6 and Search API 1.30.

RuntimeException while trying to render item entity:node/123:en with view mode default for search index Main index: Failed to start the session because headers have already been sent by "/var/www/html/vendor/symfony/http-foundation/Response.php" at line 426. in Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() (line 132 of /var/www/html/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php).

Seeing a very similar error but only when run for the command line drush cron.
The error does not appear when running it from the web interface cron.

Type | search_api
Message | Symfony\Component\HttpFoundation\Exception\SessionNotFoundException while trying to render item entity:node/1000:en with view mode default for search index Default Solr content index: Session has not been set. in Symfony\Component\HttpFoundation\Request->getSession() (line 727 of vendor/symfony/http-foundation/Request.php).

We're also seeing #29 problem on a site when indexing content via Drush.

Initially, I was seeing this error only when using Drush to index, but I just spun up a fresh environment, cloned my live database, and started indexing data via the UI. The first index completed successfully (only about 200 items), but the second index has > 8000. When the batch completed, it warned that some 700 items were not indexed. When I checked the log, I see:

Symfony\Component\HttpFoundation\Exception\SessionNotFoundException while trying to render item entity:associated_detail_products/958:it with view mode default for search index Products: Session has not been set. in Symfony\Component\HttpFoundation\Request->getSession() (line 727 of /code/vendor/symfony/http-foundation/Request.php).

But I also see:

Symfony\Component\HttpFoundation\Exception\SessionNotFoundException: Session has not been set. in Symfony\Component\HttpFoundation\Request->getSession() (line 727 of /code/vendor/symfony/http-foundation/Request.php).

Which seems to have come from simple_sitemap.

I did some searches, it looks like this SessionNotFoundException is affecting a lot of modules. I see a work around here: #3372966: Check for session before calling Request::getSession().

I did notice that cron seems to have started too, which might be another piece to the puzzle, as mentioned here: #3391783: "Session has not been set" error on drush cron.

I am seeing this on D10.2.5 and search_api 8.x-1.34

since upgrading to php8.3

RuntimeException while trying to render item entity:node/7198:en with view mode default for search index Default content index: Failed to start the session because headers have already been sent by "/vendor/symfony/http-foundation/Response.php" at line 1315. in Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() (line 132 of /vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php). 	RuntimeException while trying to render item entity:node/7198:en with view mode default for search index Default content index: Failed to start the session because headers have already been sent by "/vendor/symfony/http-foundation/Response.php" at line 1315. in Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() (line 132 of /vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php).
	
#0 /web/core/lib/Drupal/Core/Session/SessionManager.php(144): Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start()
#1 /web/core/lib/Drupal/Core/Session/SessionManager.php(109): Drupal\Core\Session\SessionManager->startNow()
#2 /vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php(311): Drupal\Core\Session\SessionManager->start()
#3 /vendor/symfony/http-foundation/Session/Session.php(222): Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->getBag()
#4 /vendor/symfony/http-foundation/Session/Session.php(242): Symfony\Component\HttpFoundation\Session\Session->getBag()
#5 /vendor/symfony/http-foundation/Session/Session.php(69): Symfony\Component\HttpFoundation\Session\Session->getAttributeBag()
#6 /web/modules/contrib/flag/src/FlagService.php(115): Symfony\Component\HttpFoundation\Session\Session->get()
#7 /web/modules/contrib/flag/flag.views_execution.inc(18): Drupal\flag\FlagService->getAnonymousSessionId()
#8 /web/modules/contrib/hook_event_dispatcher/src/HookEventDispatcherModuleHandler.php(52): flag_views_query_substitutions()
#9 /web/core/lib/Drupal/Core/Extension/ModuleHandler.php(388): Drupal\hook_event_dispatcher\HookEventDispatcherModuleHandler::Drupal\hook_event_dispatcher\{closure}()
#10 /web/modules/contrib/hook_event_dispatcher/src/HookEventDispatcherModuleHandler.php(67): Drupal\Core\Extension\ModuleHandler->invokeAllWith()
#11 /web/modules/contrib/hook_event_dispatcher/src/HookEventDispatcherModuleHandler.php(51): Drupal\hook_event_dispatcher\HookEventDispatcherModuleHandler->invokeAllWith()
#12 /web/core/modules/views/src/Plugin/views/query/Sql.php(1433): Drupal\hook_event_dispatcher\HookEventDispatcherModuleHandler->invokeAll()
#13 /web/core/modules/views/src/Plugin/views/query/Sql.php(1469): Drupal\views\Plugin\views\query\Sql->query()
#14 /web/core/modules/views/src/ViewExecutable.php(1336): Drupal\views\Plugin\views\query\Sql->build()
#15 /web/core/modules/views/src/ViewExecutable.php(1406): Drupal\views\ViewExecutable->build()
#16 /web/modules/contrib/viewfield/src/Plugin/Field/FieldFormatter/ViewfieldFormatterDefault.php(167): Drupal\views\ViewExecutable->execute()
#17 /web/core/lib/Drupal/Core/Field/FormatterBase.php(91): Drupal\viewfield\Plugin\Field\FieldFormatter\ViewfieldFormatterDefault->viewElements()
#18 /web/modules/contrib/viewfield/src/Plugin/Field/FieldFormatter/ViewfieldFormatterDefault.php(96): Drupal\Core\Field\FormatterBase->view()
#19 /web/core/lib/Drupal/Core/Entity/Entity/EntityViewDisplay.php(268): Drupal\viewfield\Plugin\Field\FieldFormatter\ViewfieldFormatterDefault->view()
#20 /web/core/modules/layout_builder/src/Entity/LayoutBuilderEntityViewDisplay.php(269): Drupal\Core\Entity\Entity\EntityViewDisplay->buildMultiple()
#21 /web/core/lib/Drupal/Core/Entity/EntityViewBuilder.php(339): Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplay->buildMultiple()
#22 /web/core/modules/node/src/NodeViewBuilder.php(24): Drupal\Core\Entity\EntityViewBuilder->buildComponents()
#23 /web/core/lib/Drupal/Core/Entity/EntityViewBuilder.php(281): Drupal\node\NodeViewBuilder->buildComponents()
#24 /web/core/lib/Drupal/Core/Entity/EntityViewBuilder.php(238): Drupal\Core\Entity\EntityViewBuilder->buildMultiple()
#25 [internal function]: Drupal\Core\Entity\EntityViewBuilder->build()
#26 /web/core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php(111): call_user_func_array()
#27 /web/core/lib/Drupal/Core/Render/Renderer.php(859): Drupal\Core\Render\Renderer->doTrustedCallback()
#28 /web/core/lib/Drupal/Core/Render/Renderer.php(421): Drupal\Core\Render\Renderer->doCallback()
#29 /web/core/lib/Drupal/Core/Render/Renderer.php(240): Drupal\Core\Render\Renderer->doRender()
#30 /web/core/lib/Drupal/Core/Render/Renderer.php(165): Drupal\Core\Render\Renderer->render()
#31 /web/core/lib/Drupal/Core/Render/Renderer.php(627): Drupal\Core\Render\Renderer->Drupal\Core\Render\{closure}()
#32 /web/core/lib/Drupal/Core/Render/Renderer.php(164): Drupal\Core\Render\Renderer->executeInRenderContext()
#33 /web/modules/contrib/search_api/src/Plugin/search_api/processor/RenderedItem.php(219): Drupal\Core\Render\Renderer->renderPlain()
#34 /web/modules/contrib/search_api/src/Item/Item.php(281): Drupal\search_api\Plugin\search_api\processor\RenderedItem->addFieldValues()
#35 /web/modules/contrib/search_api/src/Entity/Index.php(987): Drupal\search_api\Item\Item->getFields()
#36 /web/modules/contrib/search_api/src/Utility/PostRequestIndexing.php(92): Drupal\search_api\Entity\Index->indexSpecificItems()
#37 /web/core/lib/Drupal/Core/EventSubscriber/KernelDestructionSubscriber.php(51): Drupal\search_api\Utility\PostRequestIndexing->destruct()
#38 [internal function]: Drupal\Core\EventSubscriber\KernelDestructionSubscriber->onKernelTerminate()
#39 /web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func()
#40 /vendor/symfony/http-kernel/HttpKernel.php(115): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch()
#41 /web/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(63): Symfony\Component\HttpKernel\HttpKernel->terminate()
#42 /web/core/lib/Drupal/Core/DrupalKernel.php(688): Drupal\Core\StackMiddleware\StackedHttpKernel->terminate()
#43 /web/index.php(22): Drupal\Core\DrupalKernel->terminate()
#44 {main}

CORE 10.3.1
PHP 8.2
Search API: 1.35.0

RuntimeException while trying to render item entity:node/98251:en with view mode full for search index Default Content: Failed to start the session because headers have already been sent by "/var/www/html/vendor/symfony/http-foundation/Response.php" at line 408. in Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() (line 132 of /var/www/html/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php).

I am experiencing the same issue and seem it can be resolved by applying the patch provided in https://www.drupal.org/project/drupal/issues/3350137#comment-14985341 .

Thank you.

In my case I discovered that on my project the problem was with this issue on flag module.

This started for me after upgrading from Drupal 10.2.x to 10.3.x due to this change: #3413153: Remove calls to Request::hasSession().

For me, it happens when indexing a rendered_item field on a node that has a form on it (and I have immediate indexing enabled). FormBuilder::buildForm has this chunk of code:

    if ( $request->getSession()->has('batch_form_state')) {
      // We've been redirected here after a batch processing. The form has
      // already been processed, but needs to be rebuilt. See _batch_finished().
      $session = $request->getSession();
      $form_state = $session->get('batch_form_state');
      $session->remove('batch_form_state');
      return $this->rebuildForm($form_id, $form_state);
    }

So when it tries to build a form, it checks if the session has batch_form_state data set. If the session isn't yet started, it tries to start it, but NativeSessionStorage refuses to do so because the HTTP response headers have already been set (by the page's initial response).

That code should probably check that the session is actually started before checking if it has data, but I'm not really sure.

In any case, I think I'm just going to disable immediate indexing. This could quickly become wack-a-mole.

A problem here is that while the exception is now being caught by Search API and logged, the item isn't re-added to the queue (understanble, since Search API can't know if the exception will continue to happen for ever) to let cron processor take it on. So the item never gets re-indexed.

Are there many here for which the problem only occurs when indexing items immediately?
If that were the case we could maybe look into at least requeuing the item for indexing during cron if this problem happens in the post-request indexing. (Though it would be architecturally challenging, I admit.)

I'm pretty sure that won't fix the issue, it's due to that core issue, it will happen immediately or on cron, I had to remove the rendered item indexing entirely.

I use the Advanced Insert View module and for any nodes which have a view inserted they fail with this issue when indexed immediately. If indexed on cron no error and they're indexed successfully.

The same error happens on cron, it's just cron has special error suppression.

I don't think that's the behaviour I'm seeing? I put a breakpoint on the throw line here:

        if (filter_var(\ini_get('session.use_cookies'), \FILTER_VALIDATE_BOOL) && headers_sent($file, $line)) {
            throw new \RuntimeException(sprintf('Failed to start the session because headers have already been sent by "%s" at line %d.', $file, $line));
        }

When set to index immediately execution pauses on that line after saving the node. When indexing on cron I don't hit that line after saving or running cron. Don't think it's relevant, but I'm using the Ultimate Cron module.

I'm pretty sure that won't fix the issue, it's due to that core issue, it will happen immediately or on cron, I had to remove the rendered item indexing entirely.

This core issue? #3220172: NativeSessionStorage Failed start

It doesn't look like there's a bug in core there. Core is throwing an exception due to a problem created by some scenario/configuration of a site.

FWIW - For us, these errors only started occurring after updating PHP from 8.1 to 8.3.

I've been debugging our case of this further, and it appears that our site is triggering it due to the same code mentioned in https://www.drupal.org/project/search_api/issues/3274158#comment-15802027 when it tries to build a form, it checks if the session has batch_form_state data set. If the session isn't yet started, it tries to start it, but NativeSessionStorage refuses to do so because the HTTP response headers have already been set (by the page's initial response).

This can be triggered in our case either by having the content moderation form show on the page (eg. moderate node from draft to published) or the autosaveform module.

However, unlike the report in #36, in our case, when this exception is triggered, the content is still successfully updated in the index, so it doesn't seem to be causing any real problems for us.

I'm still unsure as to why it would have only started happening since we upgraded from php 8.1 to 8.3 though.

Same here when saving a taxonomy term. Sadly, don't have much helpful information yet, but I think the number of comments confirming this is enough to rate this as major bug?

What I can confirm is, that the rendered taxonomy term contains a view.

Disabling

Index items immediately

works for me as workaround and cron indexing seems to work fine then! (But only if cron runs server-side, NOT in the user session!)

I have come up against this too. In my case the error was caused by indexing the fully rendered node which also happened to include a flag form (like #32) and when that is rendered, it does some session stuff to establish an ID for anonymous users.

Where would be the correct place to address this? Should the flag module be aware of being rendered in unexpected ways or should search_api prevent it? It seems like the problem is within the realm of the Rendered HTML Output processor. I'm not sure it is best served by blindly rendering everything.

Given that the tags are stripped when it goes into the index I wonder if it's possible to just remove the forms before rendering or with a cunning hook that detects if it's being rendered normally or via indexing?

I think a good interim solution (as mentioned in in #38) would be to re-queue anything that fails to index immediately in this way. In my testing, everything has worked fine when indexing via drush (and presumably drush-based cron).

The only thing i'd add to that is that i've also seen this error in a non-search context where it was caused by something happening via Automated Cron where PrivateTempStore was inadvertently being used. The session functionality of that was triggering the same error. So it might not work if Automated Cron is being used.

I now created a merge request that would add the behavior mentioned in #38 – that is, if rendering the item fails within the “Index items immediately” behavior then it is requeued to be indexed during cron instead.
Would be great if several people could test this and confirm it resolves the issue for them. (Note that, at least with the current code, the error will still be logged but the item’s HTML will still make it into the search index, after cron runs.)

However, please be aware that it might not resolve the problem for you – this should only fix/alleviate the problem if indexing during cron works fine for you.

@very_random_man: The correct solution for that is to create a specific view mode for indexing that removes any unnecessary visual element, labels, forms, etc. This will both improve the quality of the indexed contents and should prevent your problem from happening.

Thanks for this! I've tested in a local/development instance with content that contains an embedded view (via the Advanced Insert View module) and it works as described - fails to index immediately but is indexed on the next cron run.
I'm not sure if you were intending to change the error logging, but personally I'd like to see it lowered to a notice or warning - as it is I'd likely keep the Index items immediately option disabled since it's more important for me that it's easy to scan for errors in the logs than it is to have content indexed quickly.

@drunken_monkey I think the view mode approach might be fine for basic displays. I had considered this but I felt it would open the door to maintenance issues with more complicated displays as you are basically duplicating a lot of it and creating the potential for divergence and inconsistency. I was also unsure how this would work with Layout Builder as you'd presumably need to duplicate the LB config (with the associated maintenance issues). That seemed like enough of a headache to make me abandon the idea before i went as far as seeing what happens if a node contains blocks created with the full content layout builder and rendered using a static layout builder configuration. Is that even possible?

I'd be interested to know if anyone has used this approach successfully. Maybe I am over-thinking it. It was certainly more effort than unticking a box so i went with that. :-)

If I wasn't doing that I would probably opt for a code-based approach to omit sections of the page before rendering it for the index but I prefer the lazy option of just increasing the indexing interval via drush/cron so it's almost-but-not-quite immediate.

Sorry, gone off on a bit of tangent there! Great work on the module by the way. Thanks! :-)

@gaddman: Thanks for the feedback! Good to know it works for you, and yes, makes sense to not log an error at this point. Anyone against downgrading this to a warning? (Or should it even be a notice?)

Maybe a warning is most appropriate. If the index has been configured to use immediate indexing, then the site administrator expects this to happen and a warning should be issued if it didn't for some reason.

Same here, but I've noticed this pattern (in case it helps):

- When I edit the node from /admin/content, I'm redirected back to /admin/content (with the message about a successful update), and everything works as expected - no issues.
- However, when I edit the node from the Translations UI (e.g., /node/85825/translations), I'm redirected back to the node page itself, and in this case, I encounter the error/issue mentioned above.
- Similarly, when I edit the node using the quick 'Edit' link (local tasks) from the node page itself, I'm also redirected back to the node page itself and I also encounter the error

Thanks for weighing in! Did you two also test the latest MR and check whether it alleviates the issue for you?

@dejan0: I fear the actual cause of the exception varies wildly so I don’t think we can address that here.
The basic problem is that a lot of code makes assumptions about the context in which a node/entity is rendered (or is forced to do so by missing parts in the framework) so there is no telling what might happen when rendering it in an unexpected context.
The best we can do is try to alleviate the effects of such exceptions as best we can.

Could I please get a few more testers for the MR?
With 63 followers there should be a few willing to bring this over the finish line, right?

(And just to be on the safe side: The whole purpose of the MR is to retry indexing during the next cron run if this error occurs during the node/entity save operation. It won’t change anything about that initial fail, except for downgrading the log message to a warning, and also won’t help if indexing the rendered content still fails during the cron run.)

I am having the same issue (occurs on immediate indexing) and bumped into this ticket. I did try the MR and works as described. When the issue occurs I can see the warning in the log and the content is waiting to be indexed. On the next cron run or manually starting the indexing process will re-index the content properly.

I'm running that patch (on an older version still, oh dear), but works fine! The exception is catched and logged by search api and (in this case) the node is indexed later on by cron, nice!

Thanks a lot for your feedback, sounds good!
Merged.

I also created and published a change record.

Thanks again, everyone!

Thanks so much for coming up with this smart workaround!

Maybe someone has idea...

After updating to latest version I get the this behavior:
- No exception in RenderedItem: the view render array is cached with "max-age: 0"
- If there's an exception in RenderedItem: the view render array is cached with "max-age: -1" which makes the view cached with this exact results for any query 🤯😅

@leksat: It sounds like you are talking about behavior at search time, is that correct? In that case, please create a new issue for this or take a look elsewhere (maybe debugging with git bisect) as I’m positive that this MR cannot have caused that problem.

Looks like, it's Drupal core issue.
https://www.drupal.org/project/drupal/issues/3350137#comment-16014932 #18 patch fix this issue for me on Drupal 10.5.0

I can confirm that the issue still persists on Drupal 11.2.4. Just upgraded a small site to that version from D10.5.3 and after saving a node the warning was triggered:

RuntimeException while trying to render item entity:node/134:en with view mode full for search index Search Solr Index: Failed to start the session because headers have already been sent by

Drupal 11.2.4
Search API Version: 8.x-1.39
Search API Solr Version: 4.3.10