fix: raise on attempt to change immutable vector index type (#1277)#2080
fix: raise on attempt to change immutable vector index type (#1277)#2080shaikn6 wants to merge 1 commit into
Conversation
…#1277) `collection.config.update(...)` previously ignored attempts to change a collection's vector index *type* (e.g. flat -> hnsw/dynamic). The new config was merged into the existing schema, but the index type is server-side immutable: for the legacy single-vector path the `vectorIndexType` was left untouched (a silent no-op), and for named vectors the type label was overwritten without the required reindex. Either way the user wrongly believed the change had been applied. `_CollectionConfigUpdate.merge_with_existing` now compares the requested `vector_index_type()` against the existing schema across all three update paths (`vector_index_config`, `vectorizer_config`, and `vector_config`) and raises `WeaviateInvalidInputError` with a clear message explaining that the type is immutable and the collection must be recreated and reindexed to change it. Adds unit tests in `test/collection/test_config_update.py` asserting the raise for single and named vectors and that same-type updates still merge successfully. Fixes weaviate#1277
There was a problem hiding this comment.
Orca Security Scan Summary
| Status | Check | Issues by priority | |
|---|---|---|---|
| Infrastructure as Code | View in Orca | ||
| SAST | View in Orca | ||
| Secrets | View in Orca | ||
| Vulnerabilities | View in Orca |
|
To avoid any confusion in the future about your contribution to Weaviate, we work with a Contributor License Agreement. If you agree, you can simply add a comment to this PR that you agree with the CLA so that we can merge. |
yes, I agree with the CLA |
|
you agree with the CLA |
|
I have read and agree to the Weaviate Contributor License Agreement. |
What & why
Fixes #1277.
collection.config.update(...)silently ignored attempts to change a collection's vector index type (e.g.flat→hnsw/dynamic). The vector index type is immutable server-side, but the client neither applied the change nor reported an error, so users believed the reconfiguration had taken effect when it had not.Root cause
In
_CollectionConfigUpdate.merge_with_existingthe vector-index update branches merged the newvectorIndexConfiginto the existing schema without validating the requested index type:vector_index_config/vectorizer_config): the config keys were merged but the top-levelschema["vectorIndexType"]was never touched — a silent no-op (the exact reproduction in the issue).vectorizer_configlist /vector_config):vectorIndexTypewas overwritten with the requested type without the required server-side reindex, mislabeling the index.The fix
A new helper
__check_vector_index_typecompares the requestedvector_index_type()against the existing schema's type and raisesWeaviateInvalidInputErrorwhen they differ. It is invoked in all three update paths before merging:Same-type updates (e.g. tuning
efon an existing HNSW index) continue to work unchanged. No public API signatures change, so the generated.pyistubs are unaffected.Testing
Added unit tests in
test/collection/test_config_update.py(operating onmerge_with_existing, no live Weaviate server required):test_changing_vector_index_type_single_vector_raises— reproduces Throw error message when trying to update vector index type configuration in a collection #1277 (flat → dynamic raises)test_changing_vector_index_type_via_vector_index_config_raises— deprecatedvector_index_configarg also raisestest_changing_vector_index_type_named_vector_raises/test_changing_vector_index_type_vector_config_raises— named-vector paths raisetest_same_vector_index_type_single_vector_still_updates/test_same_vector_index_type_named_vector_still_updates— allowed same-type updates still merge correctlyVerified the new "should raise" tests fail on
mainwithout the source change (DID NOT RAISE) and pass with it.Ran locally (Python 3.12):
pytest test/collection/→ 287 passed, 1 skipped (the unrelatedtest_validator.pycollection error is only due to optional heavy depsnumpy/pandas/polarsnot installed in my minimal venv; it does not touch this change)ruff format --check→ cleanflake8→ cleanpyright→ no errors inconfig.py(the 4 pre-existingconnect/v4.pyauthlib errors are present on unmodifiedmain)pydoclint→ no new findings for the added methodCLA
Per
CONTRIBUTING.md, contributions require a Contributor License Agreement (signed via the DocuSign link that the bot posts on the PR). I will sign it once it appears.