Contrib.social

Impossible to delete a server entity when Solr server is not available

Open on Drupal.org →
Created on 7 July 2025, 2 months ago

Description

Deleting an existing SearchAPI server config object is not possible if the connected Solr server is not available.

We ran into this error after deleting the configuration for an existing SearchAPI server (migrating to a different search provider). When importing the configuration to prepare our test setup in our CI the specific pipeline fails because of a SearchAPI exception thrown in in SearchApiSolrBackend::deleteAllIndexItems()
The functions calls $connector->update(); without checking first if the connection is available (in our CI environment we don't have a Solr server, so it is not).

Exception trace (excerpt):

  #11 /builds/[...]/docroot/modules/contrib/search_api_solr/src/SolrConnector/SolrConnectorPluginBase.  
  php(1067): Solarium\Core\Client\Client->execute(Object(Solarium\QueryType\Update\Query\Query), Object(Drupal\acquia_search\Client\Solarium\Endpoint))   
  #12 /builds/[...]/docroot/modules/contrib/search_api_solr/src/SolrConnector/SolrConnectorPluginBase.  
  php(1009): Drupal\search_api_solr\SolrConnector\SolrConnectorPluginBase->execute(Object(Solarium\QueryType\Update\Query\Query), Object(Drupal\acquia_search\Client\Solarium\Endpoint))                                             
  #13 /builds/[...]/docroot  
/modules/contrib/search_api_solr/src/Plugin/search_api/backend/SearchApiSolrBackend.php(1524): Drupal\search_api_solr\SolrConnector\SolrConnectorPluginBase->update(Object(Solarium\QueryType\Update\Query\Query), Object(Drupal\acquia_search\Client\Solarium\Endpoint))                                     
  #14 /builds/[...]/docroot/modules/contrib/search_api/src/Entity/Server.php(453): Drupal\search_api_solr\Plugin\search_api\backend\SearchApiSolrBackend->deleteAllIndexItems(Object(Drupal\search_api_solr\Entity\Index))                                    
  #15 /builds/[...]/docroot/modules/contrib/search_api/src/Backend/BackendPluginBase.php(225): Drupal\search_api\Entity\Server->deleteAllItems()                                   
  #16 /builds/[...]/docroot/modules/contrib/search_api/src/Entity/Server.php(579): Drupal\search_api\Backend\BackendPluginBase->preDelete()                                        
  #17 /builds/[...]/docroot/core/lib/Drupal/Core/Entity/EntityStorageBase.php(450): Drupal\search_api\Entity\Server::preDelete(Object(Drupal\search_api\Entity\SearchApiConfigEntityStorage), Array)

Setup

  • Solr version: 9
  • Drupal Core version: 10.5.1
  • Search API version: 1.38.0
  • Search API Solr version: 4.3.10
  • Configured Solr Connector:
      connector: standard
  connector_config:
    scheme: http
    host: solr
    port: 8983
    path: /
    core: search
    timeout: 5
    index_timeout: 5
    optimize_timeout: 10
    finalize_timeout: 30
    skip_schema_check: false
    solr_version: ''
    http_method: AUTO
    commit_within: 1000
    jmx: false
    jts: false
    solr_install_dir: ''

How to fix

In delete() and deleteAllIndexItems we need to call isAvailable() first to ensure the Solr instance is available.

🐛 Bug report
Status

Active

Version

4.0

Component

Code

Created by

🇩🇪Germany stborchert

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @stborchert
  • Comment 2 months ago →
    🇩🇪Germany stborchert
  • Comment 2 months ago →
    🇩🇪Germany mkalkbrenner 🇩🇪

    These two functions are part of the API. And it seems that this issue might affect any backend, not just Solr. I think, the check has to happen in Search API itself.
    Do you agree to move that issue?

  • Comment 2 months ago →
    🇩🇪Germany mkalkbrenner 🇩🇪
  • Comment 2 months ago →
    🇩🇪Germany stborchert

    Agreed.

  • Comment 15 days ago →
    🇦🇹Austria drunken monkey Vienna, Austria

    drunken monkey → made their first commit to this issue’s fork.

  • Comment 15 days ago →
    🇦🇹Austria drunken monkey Vienna, Austria

    Thanks for reporting this problem, and sorry it took me a while to get back to you!
    However, it seems that the \Drupal\search_api\Backend\BackendPluginBase::preDelete() method already catches SearchApiException when calling $server->deleteAllItems() so I’m not sure how this could lead to the operation failing? I think logging the problem makes sense, in any case, since the user should know in case they expected the server to be cleared. (In your case, I agree, it doesn’t make sense, but hard to know that.) Therefore, I’m not even sure whether wrapping this call in if ($this->isAvailable()) would be a good idea – in the end, we’d then probably still have to log a warning or error to the user explaining that we couldn’t remove our data from the server.

    In any case, could you please tell me the exact class of exception being thrown and, if it is an instance of \Drupal\search_api\SearchApiException, can you try to find out why the try/catch in BackendPluginBase::preDelete() isn’t working?

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024