Indexing policy revert and query consistency during partial re-indexing

When an indexing policy is modified on a Cosmos DB container, a background re‑indexing job begins while the container continues to accept reads and writes. The exact moment when newly indexed properties transition from partially indexed to fully queryable is not exposed as a single observable flag, and query results may return items indexed before the policy change alongside items that have not yet been re‑indexed. This creates a result‑set inconsistency window where predicates on the new attribute can yield different outcomes depending on each item's modification timestamp relative to the policy shift. Additionally, the Change feed emits per‑partition completion events, but it remains unclear whether these events guarantee that all items within a partition have reached a query‑consistent state or if in‑flight writes during re‑indexing alter the boundary. Given that abruptly stopping the job can leave items in an inconsistent index state, the operational path for a safe policy revert is ambiguous.

Under what conditions does a query on a newly indexed property guarantee result consistency across all container items? Can the Change feed alone be relied upon to signal a safe point for policy revert, or is additional tracking required? What is the impact on ongoing writes during re‑indexing regarding the visibility of index updates?