feat: add support for alter schema drop vector index

[antas-marcin]

Summary

• Add delete_vector_index(vector_name) method to collection config, allowing users to drop a named vector's index via DELETE /v1/schema/{className}/vectors/{vectorIndexName}/index
• Follows the same pattern as the existing delete_property_index method
• Includes both sync and async type stubs

Closes #1990

[orca-security-eu]

Orca Security Scan Summary

Status	Check	Issues by priority
Passed	Infrastructure as Code	0   0   0   0	View in Orca
Passed	SAST	0   0   0   0	View in Orca
Passed	Secrets	0   0   0   0	View in Orca
Passed	Vulnerabilities	0   0   0   0	View in Orca

[Copilot]

Pull request overview

Adds client support for dropping a named vector’s index via the schema REST endpoint, mirroring the existing “delete property index” capability in the collections config API.

Changes:

• Added delete_vector_index(vector_name) to the collection config executor, issuing DELETE /v1/schema/{className}/vectors/{vectorIndexName}/index.
• Added sync and async type stubs for delete_vector_index(...).

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
weaviate/collections/config/executor.py	Implements the new delete-vector-index operation via the config executor.
weaviate/collections/config/sync.pyi	Exposes the new method in the sync config type stub.
weaviate/collections/config/async_.pyi	Exposes the new method in the async config type stub.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[orca-security-eu]

Orca Security Scan Summary

Status	Check	Issues by priority
Passed	Secrets	0   0   0   0	View in Orca

[Copilot]

Pull request overview

Copilot reviewed 12 out of 12 changed files in this pull request and generated 2 comments.

[jfrancoa]

Leaving as-is for now: no public Configure.VectorIndex.* factory emits NONE (only the internal create models reference the field), and the server rejects "none" on both create and update, so the exposure is constructing private classes directly. Can add a validator in a follow-up if users actually hit it.

[bevzzz]

thought: Do you think this PR could do with fewer tests? The new endpoint is very simple and it seems to me like one "happy path" test will catch most things.

Other tests verify Weaviate's behavior more than client's logic, and some may add up to 30s of pipeline time.

[orca-security-eu]

Orca Security Scan Summary

Status	Check	Issues by priority
Passed	Infrastructure as Code	0   0   0   0	View in Orca
Passed	SAST	0   0   0   0	View in Orca
Passed	Secrets	0   0   0   0	View in Orca
Passed	Vulnerabilities	0   0   0   0	View in Orca

[jfrancoa]

@bevzzz fair point — slimmed in b92dbb7, keeping the coverage but moving it down the pyramid: the integration test is now a single happy-path journey (create → drop → poll → sibling index intact + searchable). The unknown-name case moved to the mock suite (422 → UnexpectedStatusCodeError), the invalid-input case was already covered there and its integration duplicate is deleted, and the list_all parsing assertion was already pinned by the parser unit tests. On the 30s: that's the failure-path bound of the poll — in the green path it returns as soon as the drop converges (~1-2s for a 1-object collection), so it only costs pipeline time when the feature is genuinely broken.

[jfrancoa]

@copilot review

[codecov-commenter]

Codecov Report

❌ Patch coverage is 99.43182% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 88.54%. Comparing base (95b5d76) to head (d2de164).
⚠️ Report is 96 commits behind head on main.

Files with missing lines	Patch %	Lines
integration/test_collection_config.py	96.55%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1991      +/-   ##
==========================================
+ Coverage   86.64%   88.54%   +1.90%     
==========================================
  Files         300      305       +5     
  Lines       23172    23720     +548     
==========================================
+ Hits        20077    21003     +926     
+ Misses       3095     2717     -378     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[dirkkul]

a few smaller things, none of them blocking:

• the delete_vector_index docstring goes stale as soon as the endpoint is promoted or the status code changes: it names ENABLE_EXPERIMENTAL_ALTER_SCHEMA_DROP_VECTOR_INDEX_ENDPOINT=true and says the server answers 500 without it. someone reading it after that sets an env var the server no longer looks at. could we say the endpoint is experimental and may be disabled server-side, without naming the flag or the status code?

• in test/collection/test_config_methods.py, test_collection_config_simple_from_json_with_dropped_vector_index and test_collection_config_simple_from_json_all_vectors_dropped parse the same schemas as the two non-simple tests above them - __get_vector_config(schema, simple) never reads simple, and __get_vectorizer takes no such parameter. the simple path does build a different dataclass, so could we keep one of the two as the list_all() guard and drop the other?

• test_delete_vector_index_endpoint_disabled overlaps the 422 case already inside test_delete_vector_index - both assert that a non-OK status comes back as UnexpectedStatusCodeError carrying the status code. the one thing it adds is that the server's error message reaches the exception, so could that move into test_delete_vector_index as another status/message case instead of standing up its own mock server?

reviewed with claude code, I went through every comment below myself

[dirkkul]

This seems like a test that should be in Weaviate and not the python client

[jfrancoa]

But it's basically testing a python functionality, the merge_with_existing. If this test would go as a go acceptance test it wouldn't invoke the same logic imho. It's not even using a Weaviate instance.

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated no new comments.

[dirkkul]

two more things on the config output, both about the export => import round trip:

• a dropped vector comes back with vector_index_config: None, so its index type is only visible after to_dict(). could we add a small _VectorIndexConfigNone with vector_index_type() -> "none" and keep the union concrete instead of widening it with None? _NamedVectorConfig.to_dict() would lose its special case and you could branch on vector_index_type() like for every other index. it should still leave vectorIndexConfig out of the output so the dict keeps matching what the server sent.

• exporting a collection that has a dropped vector and importing it back fails today: the server refuses vectorIndexType: "none" on create and to_dict() passes the entry straight through. I think we should strip those entries in __create, since that's the one place create(), create_from_dict() and create_from_config() all go through. the whole vectorConfig entry, not just the type - stripping only the type would recreate an hnsw index for a vector that was deliberately dropped. that's also where the server ends up by itself: the cleanup task removes the entry once the drop finalizes. probably worth a warning naming the skipped vectors, otherwise inserts targeting them fail later with a confusing error.

where the server rejects it

usecases/schema/class.go, on the create path:

if modelsext.IsVectorIndexDropped(cfg) {
    return fmt.Errorf("vector %q: cannot create a new class with vectorIndexType %q; "+
        "this is an internal sentinel for dropped indexes", name, cfg.VectorIndexType)
}

and rejectVectorIndexTypeNone blocks both introducing and reviving the sentinel through a class update. so client.collections.create_from_config(src.config.get()) answers 422 for any collection that ever had a vector index dropped.

either way the round trip can't be lossless - there is no api to recreate a vector without an index, so the imported collection simply doesn't have that vector. might be worth saying that in the create_from_dict docstring.

reviewed with claude code, I went through every comment below myself

[Copilot]

Pull request overview

Copilot reviewed 15 out of 15 changed files in this pull request and generated 2 comments.

Suppressed comments (1)

weaviate/collections/collections/base.py:124

• This docstring references collection.config.delete_vector_index without parentheses, which reads like an attribute instead of a method. Consider using collection.config.delete_vector_index() to make it clear this is a callable API.

        Vector entries whose index was dropped with `collection.config.delete_vector_index` are
        skipped with a warning: there is no API to re-create a vector without an index, so the new
        collection simply does not contain them.