clear_documents leaves other embedding models' vector containers intact

Summary

With model isolation, a workspace can own one vector container per embedding model. /documents/clear drops only the container the running instance is configured for, so a clear performed under model B leaves model A's vectors in place. Switching back to A attaches to them, and naive retrieval can return chunk content the operator believed deleted — while the authoritative KV, graph and doc-status stores were cleared.

This affects every model-isolated backend

Not specific to one implementation — each drop() targets its own suffixed container and stops there:

backend	what drop() removes
Milvus	final_namespace (the active model's collection)
PostgreSQL	table_name (the active model's table) + the legacy table's workspace rows
Qdrant	final_namespace's workspace points + the legacy collection's
OpenSearch	_index_name (the active model's index)

None enumerates sibling model variants.

Why it needs one decision rather than four

Two questions have to be answered together, and answering them per-backend would make destructive semantics diverge:

1. Does "clear this workspace" mean every model's vectors, or the active model's? The isolation feature exists so a model switch is reversible, which argues for keeping siblings; the clear contract argues the opposite. They genuinely conflict.
2. What happens to the legacy (pre-isolation) container? PostgreSQL and Qdrant already clear it on drop, because they gate migration on the destination being empty and would otherwise re-migrate it on the next start. A backend that gates differently has no such need. Any rule about siblings has to say what it means for the legacy one too.

Found by

Codex review on #3966, which brings OpenSearch into the model-isolation scheme and therefore inherits the gap. That PR documents the boundary on OpenSearchVectorDBStorage.drop() rather than diverging from the other three unilaterally.

Sketch, not a decision

If siblings should be cleared, each backend needs a way to enumerate the containers a workspace owns — by ownership metadata rather than by name pattern, since names fold (see #3967) and a pattern match could take another deployment's container. A shared helper on BaseVectorStorage would keep the four honest; a per-backend implementation would not.

Generated with Claude Code