On this page
The short answer
Test cache invalidation with a warm cache before changing source evidence. Verify that the next eligible answer uses the intended revision and authorization scope rather than assuming a successful reindex invalidates every cached representation.
What to take away
- Distinguish response and retrieval caches.
- Include source and permission changes.
- Inspect cached evidence versions.
Sources checked . Research synthesis and Rubrex recommendations. Examples and local experiments are labeled; they are not client results.
Map the cache layers
Azure documents source-change detection for indexing, which is only one part of a cached RAG path. Identify response caches, retrieved-context caches, query-rewrite caches, and any parent or summary lookup caches the application uses. Define which inputs make a cache entry valid: corpus revision, user scope, date basis, prompt, model, and relevant retrieval settings. Do not assume a textually identical query means the same authorized question across different users or source revisions.
Evidence: Change and delete detection using indexers [1]Run or reset indexers [2]
Create a warm-cache update example
Author a fictional shipping policy with a five-day promise. Ask a question to populate the supported caches, then change the approved source to seven days. After the intended update boundary, repeat the query with the same user and with another authorized user. The expected evidence and answer must reflect the applicable revision. Add a policy-permission change without a text edit to check whether an unchanged content hash improperly keeps the old eligibility decision alive.
Inspect the evidence actually served
Record cache hit or miss, entry identity, source revisions, authorization scope, and final context IDs. A cached answer can be wrong even when a direct search returns the new source. A cache miss can still use stale parent data farther downstream. Probe each layer rather than treating one hit-rate graph as proof of correctness. Keep service failures and stale-but-confirmed reads separate so an unavailable cache is not misclassified as successful invalidation.
Define acceptable behavior during transition
Some systems invalidate immediately; others use bounded expiration or explicit version keys. Test the configured promise rather than requiring one implementation universally. Decide whether the application may serve dated evidence with a qualification while an update propagates. For access revocation, evaluate the security boundary independently from ordinary freshness. A convenient stale response may be unacceptable even if the user-facing text is accurate. Include a control case whose evidence remains unchanged so invalidation does not needlessly destroy every useful cache entry.
Make invalidation observable and reversible
Preserve synthetic update cases in the regression suite and rerun them after changes to cache keys, indexes, or authentication scope. Record the first stale read and first confirmed valid read against the chosen boundary. If a fix changes key construction, check both collisions and excessive misses. The decision should explain which evidence versions can be served and why, rather than optimizing hit rate alone. Retain enough lineage to diagnose a stale answer without storing unnecessary copies of sensitive source content. Include a deliberate cache-key collision test using different effective dates. If both questions share cached evidence, inspect whether the date basis was omitted from key construction.
Limits of the evidence
This is a cache correctness test plan, not a latency benchmark or a guarantee of immediate deletion. Security-sensitive invalidation needs the application’s explicit access policy.
Common questions
Does reindexing clear a response cache?
Only if your integration makes that happen; test the actual cache layers and keys.
Can identical questions share entries across users?
Only when the authorized evidence and relevant scope are equivalent under a verified policy.
Sources & further reading
Primary sources behind this briefing. A source’s findings apply to its own study conditions; publication on arXiv does not establish peer review.
- Change and delete detection using indexers Microsoft · Living reference · Maintained documentationReviewed: change tracking and explicit deletion detection requirements. Accessed October 16, 2026.
- Run or reset indexers Microsoft · Living reference · Maintained documentationReviewed: indexer change tracking, reset and resynchronization distinctions. Accessed October 16, 2026.
Questions or corrections? Write to Rubrex. Read our editorial approach.