Check how the rows were removed. A source job used TRUNCATE on a table feeding an AI search index. The connector was configured to publish inserts, updates and deletes, but not truncates, or its downstream consumer only understands row-level changes. There is no per-row delete for the indexer to apply. The log consumer can be fully caught up on every event it was actually given while every old vector remains. PostgreSQL publications can choose published operations, including TRUNCATE. The default publication setting includes it in current PostgreSQL, so this scenario requires an explicit exclusion or a consumer that drops that message. Check the deployed database version and connector contract.

I would compare the source's table state with the publication definition, replication events and the index consumer's supported operation types. Was the table included? Was a truncate emitted? Did the connector deserialize it? Did the indexer treat it as an unknown event and still advance its checkpoint? Identify the first boundary where the operation disappeared. A lag metric at the end of the pipeline cannot tell us whether the source published the needed semantic event.

For recovery, stop answering from the affected index generation, or apply a source-authoritative generation marker that excludes those records while a rebuild runs. A truncate is a set-level operation. Deleting a guessed list of row IDs from yesterday's index is fragile if the source has already started inserting new rows. Define an epoch or snapshot boundary, reconcile current source contents and tombstone records from the prior epoch. Only declare freshness restored after a complete comparison or an event stream with a provable handoff.

The next pushback is that TRUNCATE might not mean legal deletion. Correct. The owner of the source must define whether it is a maintenance reset, a bulk replacement or a real delete, and downstream products need the matching policy. The Delta table deleted a customer row. Why does vector search still return it? covers a deleted Delta row left in vector search, and A deleted customer document returned after an index rebuild. Which deletion did replay miss? covers a deletion lost during replay. This case is about a different operation type never reaching the index as row deletes.