Deletion of chunks vectors fails upon saving a node after editing

Additional investigation

Confirmed against current 1.0.x with normal Search API dynamic indexing.

The existing patch fixes the immediate mismatch by changing the final delete to use id, and raises the lookup limit. There is a simpler path: deleteItems() already receives the Search API item IDs (for example entity:node/1174:en), while deleteFromCollection() already deletes on drupal_entity_id.

The proposed follow-up changes deleteItems() to pass those item IDs directly to deleteFromCollection(). This avoids the primary-key lookup entirely. In particular, it avoids both the original identifier mismatch and a fixed lookup limit.

The resulting statement is effectively:

DELETE FROM collection
WHERE drupal_entity_id IN ('entity:node/1174:en');

That removes every stored chunk for the item before the fresh chunks are inserted.

How to test

1. Configure the Postgres VDB provider on a Search API index.
2. Create or use an item that produces more than ten chunks, then index it normally.
3. Record the row count for its drupal_entity_id.
4. Save the unchanged entity and allow normal dynamic Search API indexing to complete.
5. Verify that the row count is unchanged, rather than doubled.
6. Change a distinctive phrase in the entity, save and index it again, then verify no stored chunk contains the old phrase.

We verified the equivalent scenario in a sandbox: re-saving an item with 341 chunks left 341 rows, not 682, and a search for a marker in the final chunk still returned the item.

Hm, had issues pushing my changes. Pushed it over the original MR: https://git.drupalcode.org/project/ai_vdb_provider_postgres/-/merge_requ...

The old changes are in a separate branch (pre-rebase, as I rebased on latest 1.0.x).

Follow-up: progressive indexing passes

I added a second, focused commit to the same MR. The first commit makes deletion target the correct drupal_entity_id; this also means the Postgres provider must honor AI Core's skipDeleteItemIds list. Its indexItems() override previously ignored that list and deleted the item's earlier chunks again on every progressive continuation pass, leaving only the final slice.

The follow-up excludes in-progress item IDs from deletion. The first pass still removes all stale vectors after an entity update, while later passes retain the new chunks already written. This belongs to the same issue because it completes the delete-before-reindex lifecycle.

Tested through a normal Drupal node save and Search API indexing: the initial article progressed 10 → 20 → 30 → 33 chunks. After replacing the body, it progressed 10 → 20 → 27. No stale marker remained, and the replacement tail marker was indexed.