A tombstone is a record of a deletion, but it does not promise infinite replay time. Kafka's design documentation explains log compaction and says consumers need to reach the head before the tombstone retention interval to be guaranteed to see delete markers. A current compacted log can represent the live key set correctly while an index rebuilt from a separate, stale snapshot remains wrong if the delete fell outside its valid replay window. Check the actual topic cleanup and retention settings too. Do not assume that reading from offset zero, when the old history may already have been cleaned, repairs an arbitrarily old snapshot.

I would reconstruct the timeline with the source version and deletion time for X, snapshot high-water mark, Kafka partition and offset, tombstone production and retention, rebuild replay starting offset, and final index write. There are other plausible causes: the producer never emitted the tombstone, the key format changed between update and delete, or a stale event applied after the delete. The failure is not proven by the mere age of the snapshot. Find the exact missing transition and compare it against the authoritative source of current documents.

For a reliable rebuild, use a fresh source snapshot with a well-defined change boundary and replay changes from an offset retained since that boundary, or rebuild from a trustworthy current compacted view without mixing it with an older state. If neither guarantee is available, rescan the source or reconcile the rebuilt key set against authoritative current state before serving it. Keep deletion versions or durable negative state when the system needs to reject an older upsert during replay. An offset is meaningful per partition. The handoff from snapshot to log must account for keys moving and for duplicate delivery.

Would I extend tombstone retention forever? Usually no. Retention can buy enough time for the slowest supported bootstrap, but it is not a substitute for a bounded recovery contract and a measured rebuild duration. A bulk snapshot races the change stream deals with snapshot racing a live change stream. Here the snapshot can be much older than the replay guarantee. The document was deleted yesterday. Why is the assistant still quoting it? asks why a deleted document is still quoted in normal operation. This is a specific rebuild path that can reintroduce a delete after the live index had already removed it.