Why does my Drupal Solr index data get reset or disappear after config import?

Drupal
Critical Bug — Search API

Silent Index Data Loss During Config Import

A known bug in Drupal's Search API module causes complete deletion of all indexed documents when drush config:import runs on sites using Config Split.

What Happens

If your Drupal site uses Config Split to manage per-environment Search API server assignments (a very common and officially recommended pattern), every drush config:import can silently wipe your entire Solr index — hundreds of thousands of documents, gone instantly with no warning.

The deletion is completely silent. No watchdog entry, no drush output, no confirmation prompt. Drupal's tracker still reports all items as indexed, so the data loss is invisible until someone searches and gets zero results.

Root Cause

The bug is in Search API's reactToServerSwitch() method. Here is the exact chain of events:

Step 1
Config import runs
drush config:import
→
Step 2
Server set to null
Base config applied first
→
Step 3
deleteAllIndexItems()
ALL data wiped from Solr
→
Step 4
Patch restores server
Too late — data is gone

The detailed code path:

  1. Index::postSave() fires when the index config is saved during import and calls reactToServerSwitch().
  2. reactToServerSwitch() compares the current server ID (now null from base config) with the original (the real server). They differ, so it calls removeIndex() on the old server.
  3. BackendPluginBase::removeIndex() calls deleteAllIndexItems() unconditionally.
  4. SearchApiSolrBackend::deleteAllIndexItems() sends a DELETE BY QUERY to Solr: +index_id:YOUR_INDEX +hash:YOUR_HASH — every document is permanently deleted.
  5. Config Split patch then applies and restores the correct server — but the data is already gone.

Why Config Split Triggers This

Config Split is the standard Drupal way to manage per-environment configuration. A typical setup stores server: null in the base index config, with per-environment patches that add the correct server:

# config/envs/prod/config_split.patch.search_api.index.your_index.yml
adding:
  server: your_solr_server
removing:
  server: null

During drush config:import, the base config is processed before the Config Split patch. The index momentarily has server: null, which Search API interprets as a server switch, triggering the destructive delete.

How to Fix It (Workarounds)

Until the upstream bug is fixed, these workarounds will protect your data:

Recommended — Bulletproof

settings.php Override

Add $config overrides in settings.php to hard-wire the server assignment. This takes absolute precedence over config import and Config Split — the server can never be null at runtime.

Alternative

Config Ignore

Add search_api.index.* to your config_ignore settings so config import never touches index config at all.

Long-term

Fix Base Config

Change your base config YAML to include the correct server: your_server_id instead of null. Remove the server toggling from Config Split patches.

Recommended fix — add this to your settings.php:

// Prevent config import from ever setting server to null on indexes
$config['search_api.index.YOUR_INDEX_ID']['server'] = 'your_server_id';

Is Opensolr Involved?

No. The delete is a normal DELETE BY QUERY request that your Drupal site sends to the Solr index, and Solr runs it as sent. Opensolr does not start, change or block it: the deletion comes from the Search API module code.

Upstream Bug Report

We have filed a bug report with the Search API Solr project on Drupal.org. You can track the progress of the fix here:

Issue #3583585: reactToServerSwitch() causes complete data loss when config import temporarily sets server to null

More on Drupal and Opensolr: Drupal Setup with Opensolr and Opensolr Connection Issues.