### Problem/Motivation When multiple Search API indexes share the same Vector Database (VDB) collection (table), index management operations (such as deleting items or clearing an index) cause silent and permanent data loss in other indexes sharing that collection: 1. **When individual items are deleted/re-indexed:** Deleting items with overlapping `drupal_entity_id`s (e.g., `node/1` exists in both Index A and Index B) from one index unintentionally deletes them from all other indexes in the vector database. 2. **When an index is cleared:** Running "Clear indexed data" on one index completely drops and recreates the shared database collection/table, instantly wiping out all other indexes' data in that collection. Because Search API maintains its own tracking tables, it remains unaware that the records in the vector database have been deleted, leading to an out-of-sync state where queries on unaffected indexes silently return incomplete or empty results. ### Root Cause Analysis (RCA) #### 1. Issue with `deleteItems()` The individual item deletion pipeline lacks index-specific filtering: * **`SearchApiAiSearchBackend::deleteItems()`** invokes **`AiVdbProviderClientBase::deleteIndexItems()`**, passing the `$index` object. * **`AiVdbProviderClientBase::deleteIndexItems()`** forwards the deletion to `deleteItems($configuration, $item_ids)`, dropping the `$index` context entirely. * **`PostgresProvider::getVdbIds()`** (or **`AiVdbProviderClientBase::deleteItems()`**) retrieves row IDs via: ```sql SELECT id FROM {collection_name} WHERE drupal_entity_id IN (:prepared_drupal_ids); ``` Since this query does not filter by `index_id`, it returns primary keys of matching entities across **all** indexes sharing that collection, leading to their deletion. #### 2. Issue with `deleteAllItems()` The clear-index pipeline drops the entire collection: * **`SearchApiAiSearchBackend::deleteAllItems()`** invokes **`AiVdbProviderClientBase::deleteAllIndexItems()`**, passing the `$index` object. * **`AiVdbProviderClientBase::deleteAllIndexItems()`** forwards this to `deleteAllItems($configuration, $datasource_id)`, dropping the `$index` context. * **`AiVdbProviderClientBase::deleteAllItems()`** proceeds to drop and recreate the entire table: ```php $this->dropCollection( collection_name: $configuration['database_settings']['collection'], database: $configuration['database_settings']['database_name'], ); ``` This immediately destroys all indexed data for every other search index sharing that collection. ### Steps to Reproduce 1. Configure two Search API indexes (**Index A** and **Index B**) targeting different content types or sub-sites, but configured to use the same Postgres/VDB collection. 2. Index items on both indexes. Ensure some items have overlapping `drupal_entity_id`s (e.g. `entity:node/1:en`). 3. **Reproduce delete issue:** Trigger a rebuild/indexing sequence on **Index A**. Observe that the corresponding overlapping entries for **Index B** are deleted from the database table. 4. **Reproduce clear-index issue:** Click "Clear indexed data" on **Index A**. Observe that **Index B**'s data is entirely wiped from the database collection. ### Proposed Resolution Because **`deleteIndexItems()`** and **`deleteAllIndexItems()`** both have access to the `$index` object, we should preserve and leverage this context: 1. Update the VDB provider interface/base class methods so that deletion operations can filter by `index_id`. 2. Update individual deletions (e.g., in `getVdbIds()`) to include the `index_id` in the query: ```sql WHERE drupal_entity_id IN (:ids) AND index_id = :index_id ``` 3. Update `deleteAllItems()` to delete rows matching the specific `index_id` (and optionally `datasource_id`) via a `DELETE` query rather than dropping the entire collection, unless the collection is exclusive to a single index.