# Delete a source that has already produced an answer

Test withdrawal after the system has created passages, caches and conversation history. An empty search result alone does not prove removal is complete.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Prepare a recognisable fixture

Create a synthetic document with a unique instruction, such as routing a test request to queue ALPHA-47. Generate an answer from it and save the conversation. Repeat the question until any answer cache used by the application is populated.

Record the document key, revision, passage identifiers and answer identifier. The unique queue name helps trace accidental reuse without relying on the wording of a generated sentence. Use a fixture rather than a real sensitive document so the test itself does not create a retention problem.

Establish the expected product behaviour before deleting anything. Should the old conversation remain visible with an outdated notice, lose the source excerpt or become inaccessible? Different requirements need different assertions.

## Withdraw the source while work is in flight

Remove or withdraw the fixture through the normal source process. Keep one ingestion job for the previous revision delayed, then allow it to finish after the deletion event. This tests whether late work can recreate a withdrawn passage.

Do not skip the connector. Directly deleting the index record only tests the final storage operation. The real failure may be a source system that never emits a deletion event or a poller that advances its checkpoint before recording the removal.

For platforms with soft-delete detection, verify that the source's retention period and indexing schedule allow the deletion marker to be observed. The particular settings depend on the connector. The test should establish the behaviour of the configuration you actually use.

## Exercise each way a reader can return

Run the original question in a new session, repeat it in the existing session and open the saved answer directly. Inspect source identifiers and cached response metadata. A rephrased answer can still contain the withdrawn instruction.

Try a question that retrieves a neighbouring passage from the same document. This catches incomplete removal when one source produced many chunks. Also test a query with no cached answer to separate stale retrieval from stale generation output.

If the product offers export or sharing, include those paths. They may use a stored answer representation that bypasses the normal retrieval checks.

## Observe the stopping point

Measure when the last prohibited serving path stops returning the withdrawn material. Record any interval during which the system knowingly serves stale evidence and confirm whether it meets the agreed requirement.

Finally, replay the old source event and restart the relevant worker. The fixture should remain withdrawn. Keep these steps as a regression test because ordering bugs often return during connector or queue changes. A successful run demonstrates both removal and resistance to accidental resurrection, which are separate properties.

## Sources

- [Microsoft Learn: changed and deleted source blobs](https://learn.microsoft.com/en-us/azure/search/search-how-to-index-azure-blob-changed-deleted)
- [Microsoft Learn: monitor indexer status](https://learn.microsoft.com/en-us/azure/search/search-monitor-indexers)