Documentation > Drupal

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

Drupal
Critical Bug — Search API Solr

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. Opensolr receives a perfectly valid DELETE BY QUERY request from the Drupal application and executes it as instructed. We do not initiate, modify, or interfere with these requests. The deletion is entirely caused by Drupal's Search API module code. No actions appear in the Opensolr action log because no Opensolr operations took place — the delete comes directly from Drupal to the Solr server.

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

Need Help?

If you're experiencing this issue on Opensolr, our support team can help you verify the cause and apply the workaround.

Contact Support Drupal Integration Docs