[TST] add schema proptest to python

[jairad26]

Description of changes

Summarize the changes made by this PR.

• Improvements & Bug fixes
  • Adds prop tests to distributed & local chroma for e2e create_collection and get_collection flow to ensure all reconciliation logic for vector index config, and schema index configs for inverted indexes on metadata keys & sparse vector indexes are created with the correct parameters
• New functionality
  • ...

Test plan

How are these changes tested?

• Tests pass locally with pytest for python, yarn test for js, cargo test for rust

Migration plan

Are there any migrations, or any forwards/backwards compatibility changes needed in order to make sure this change deploys reliably?

Observability plan

What is the plan to instrument and monitor this change?

Documentation Changes

Are all docstrings for user-facing APIs updated if required? Do we need to make documentation changes in the docs section?

[github-actions]

Reviewer Checklist

Please leverage this checklist to ensure your code review is thorough before approving

Testing, Bugs, Errors, Logs, Documentation

• Can you think of any use case in which the code does not behave as intended? Have they been tested?
• Can you think of any inputs or external events that could break the code? Is user input validated and safe? Have they been tested?
• If appropriate, are there adequate property based tests?
• If appropriate, are there adequate unit tests?
• Should any logging, debugging, tracing information be added or removed?
• Are error messages user-friendly?
• Have all documentation changes needed been made?
• Have all non-obvious changes been commented?

System Compatibility

• Are there any potential impacts on other parts of the system or backward compatibility?
• Does this change intersect with any items on our roadmap, and if so, is there a plan for fitting them together?

Quality

• Is this code of a unexpectedly high quality (Readability, Modularity, Intuitiveness)

[jairad26]

• [TST] add proptest for config & schema reconciliation #5847
• [TST] add schema proptest to python #5823 👈 (View in Graphite)
• [CLN] schema: build default with config ef & default_knn_index, remove #document population in defaults #5775
• [BUG] is_default_schema does not do a space check for defaults or #embedding #5787
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[propel-code-bot]

Add Hypothesis-based schema reconciliation tests for collection creation

Introduces comprehensive property-based tests covering collection creation and retrieval across local and distributed configurations. The new suites validate reconciliation between metadata, explicit configuration, and schema-provided vector/index settings for both HNSW and SPANN modes, ensuring collection state (configuration blocks, schema defaults/keys, and embedding function metadata) matches expectations derived from randomized inputs.

Key Changes

• Added test_vector_index_configuration_create_collection Hypothesis test to validate active vector index configuration against metadata/config/schema permutations for both HNSW and SPANN backends
• Added test_schema_create_and_get_collection Hypothesis test to verify persistence of schema-defined inverted and sparse indexes through create/get flows
• Extended chromadb/test/property/strategies.py with strategies for vector index configs, sparse index configs, schema construction, metadata/configuration combinations, and supporting utilities (CollectionInputCombination, non_none_items, vector_index_to_dict)
• Registered new SimpleIpEmbeddingFunction (default space ip) for property tests and wired deterministic sparse embedding support into strategies

Affected Areas

• chromadb/test/property/test_schema.py
• chromadb/test/property/strategies.py

This summary was automatically generated by @propel-code-bot

[propel-code-bot]

[BestPractice]

Potential KeyError risk: The code accesses HNSW_DEFAULTS[key] on lines 128 and 197 without checking if the key exists in the dictionary. If a key from hnsw_non_none is not present in HNSW_DEFAULTS, this will raise a KeyError. Add a safety check:

if key in HNSW_DEFAULTS and value is not None and value != HNSW_DEFAULTS[key]:
    should_try_metadata = False

This prevents crashes when unexpected configuration keys are encountered.

Context for Agents

[**BestPractice**]

Potential KeyError risk: The code accesses `HNSW_DEFAULTS[key]` on lines 128 and 197 without checking if the key exists in the dictionary. If a key from `hnsw_non_none` is not present in `HNSW_DEFAULTS`, this will raise a `KeyError`. Add a safety check:

```python
if key in HNSW_DEFAULTS and value is not None and value != HNSW_DEFAULTS[key]:
    should_try_metadata = False
```

This prevents crashes when unexpected configuration keys are encountered.

File: chromadb/test/property/test_schema.py
Line: 128

[propel-code-bot]

[Maintainability] The function _compute_expected_config is quite long and handles two distinct logical paths based on spann_active. To improve readability and maintainability, consider splitting this function into two smaller, focused helpers: one for the SPANN logic and one for the HNSW logic.

This would make the complex reconciliation logic easier to understand and maintain for each vector index type.

Example structure:

def _compute_expected_config_spann(
    metadata: Optional[CollectionMetadata],
    configuration: Optional[CreateCollectionConfiguration],
    schema_vector_index_config: Optional[Dict[str, Any]],
) -> Dict[str, Any]:
    # ... logic from the `if spann_active:` block ...

def _compute_expected_config_hnsw(
    metadata: Optional[CollectionMetadata],
    configuration: Optional[CreateCollectionConfiguration],
    schema_vector_index_config: Optional[Dict[str, Any]],
) -> Dict[str, Any]:
    # ... logic from the `else:` block ...

def _compute_expected_config(
    spann_active: bool,
    metadata: Optional[CollectionMetadata],
    configuration: Optional[CreateCollectionConfiguration],
    schema_vector_index_config: Optional[Dict[str, Any]],
) -> Dict[str, Any]:
    if spann_active:
        return _compute_expected_config_spann(
            metadata, configuration, schema_vector_index_config
        )
    else:
        return _compute_expected_config_hnsw(
            metadata, configuration, schema_vector_index_config
        )

Context for Agents

The function `_compute_expected_config` is quite long and handles two distinct logical paths based on `spann_active`. To improve readability and maintainability, consider splitting this function into two smaller, focused helpers: one for the SPANN logic and one for the HNSW logic.

This would make the complex reconciliation logic easier to understand and maintain for each vector index type.

Example structure:
```python
def _compute_expected_config_spann(
    metadata: Optional[CollectionMetadata],
    configuration: Optional[CreateCollectionConfiguration],
    schema_vector_index_config: Optional[Dict[str, Any]],
) -> Dict[str, Any]:
    # ... logic from the `if spann_active:` block ...

def _compute_expected_config_hnsw(
    metadata: Optional[CollectionMetadata],
    configuration: Optional[CreateCollectionConfiguration],
    schema_vector_index_config: Optional[Dict[str, Any]],
) -> Dict[str, Any]:
    # ... logic from the `else:` block ...

def _compute_expected_config(
    spann_active: bool,
    metadata: Optional[CollectionMetadata],
    configuration: Optional[CreateCollectionConfiguration],
    schema_vector_index_config: Optional[Dict[str, Any]],
) -> Dict[str, Any]:
    if spann_active:
        return _compute_expected_config_spann(
            metadata, configuration, schema_vector_index_config
        )
    else:
        return _compute_expected_config_hnsw(
            metadata, configuration, schema_vector_index_config
        )
```

File: chromadb/test/property/test_schema.py
Line: 97