What happened
create_collection writes to two systems that share no transaction: it creates a native collection in the vector database, then records the collection in the registry. No ordering makes that atomic, so every choice is a choice about which garbage to leave.
Today's ordering is native-first, register-last, which is the safe one — a crash leaves an empty native collection rather than a registered collection with nowhere to put records. It is safe, though, only because native names are content-addressed and creation is idempotent, so the orphan is adopted by the next creation with the same config rather than leaked. That precondition is unstated, and it is load-bearing: a backend whose containers are named per-collection rather than per-config leaks one container per crashed creation, and nothing in the code says why that is different.
The deeper problem is that the dual write exists at all. Native containers are heavyweight, few, and slow to create — a Pinecone index takes minutes, and providers cap them at 20 to 1000 — while logical collections are numerous and created at runtime. These are control-plane and data-plane concerns being done in one call.
Expected
Creating a logical collection should touch one transactional system, so it is atomic by construction and needs no ordering argument. Native containers should already exist when a collection is created.
Suggested direction
Move native container creation off the create path and into provisioning: a step that reads configuration and idempotently ensures the containers a deployment needs, run before serving rather than from a request. create_collection then becomes a single registry insert, arbitrated by a primary key.
This is the same problem and the same answer shape as #1570, which covers SQL schema provisioning running from every process's boot path. The two should share one provisioning entry point rather than inventing separate mechanisms — "create the tables" and "create the containers" are the same step for different resources.
Whatever is left over is then reclaimable rather than merely harmless: see #1565.
Notes
Related to #1524 and #1525, which cover the cross-process races in collection metadata. This issue is about the create path spanning two systems at all, which remains true however well the metadata side is arbitrated.
What happened
create_collectionwrites to two systems that share no transaction: it creates a native collection in the vector database, then records the collection in the registry. No ordering makes that atomic, so every choice is a choice about which garbage to leave.Today's ordering is native-first, register-last, which is the safe one — a crash leaves an empty native collection rather than a registered collection with nowhere to put records. It is safe, though, only because native names are content-addressed and creation is idempotent, so the orphan is adopted by the next creation with the same config rather than leaked. That precondition is unstated, and it is load-bearing: a backend whose containers are named per-collection rather than per-config leaks one container per crashed creation, and nothing in the code says why that is different.
The deeper problem is that the dual write exists at all. Native containers are heavyweight, few, and slow to create — a Pinecone index takes minutes, and providers cap them at 20 to 1000 — while logical collections are numerous and created at runtime. These are control-plane and data-plane concerns being done in one call.
Expected
Creating a logical collection should touch one transactional system, so it is atomic by construction and needs no ordering argument. Native containers should already exist when a collection is created.
Suggested direction
Move native container creation off the create path and into provisioning: a step that reads configuration and idempotently ensures the containers a deployment needs, run before serving rather than from a request.
create_collectionthen becomes a single registry insert, arbitrated by a primary key.This is the same problem and the same answer shape as #1570, which covers SQL schema provisioning running from every process's boot path. The two should share one provisioning entry point rather than inventing separate mechanisms — "create the tables" and "create the containers" are the same step for different resources.
Whatever is left over is then reclaimable rather than merely harmless: see #1565.
Notes
Related to #1524 and #1525, which cover the cross-process races in collection metadata. This issue is about the create path spanning two systems at all, which remains true however well the metadata side is arbitrated.