Repository navigation
Chroma: update ChromaDotNet.Client to 2.14.0, reject reserved storage names, support nullable inline arrays - #69
Merged
Conversation
….5.9, and two errors on Chroma Cloud
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
The new validation still permits $-prefixed metadata names that Chroma rejects during writes.
1 open finding
What changed in this PR
Adds safer Chroma model validation, nullable inline-array filtering, updated client behavior, and documented service limitations.
Changes:
- Rejects
#-prefixed metadata storage names. - Supports nullable inline arrays in
Containsfilters. - Updates ChromaDotNet.Client and provider documentation/version.
| File | Description |
|---|---|
MEVD/test/Chroma.UnitTests/ChromaHotel.cs |
Adds a reserved-name test model. |
MEVD/test/Chroma.UnitTests/ChromaFilterTranslatorTests.cs |
Tests nullable inline-array translation. |
MEVD/test/Chroma.UnitTests/ChromaCollectionTests.cs |
Tests storage-name validation. |
MEVD/src/Chroma/README.md |
Documents Chroma limitations and mitigations. |
MEVD/src/Chroma/ChromaModelBuilder.cs |
Validates reserved metadata prefixes. |
MEVD/src/Chroma/ChromaFilterTranslator.cs |
Extracts converted nullable constants. |
MEVD/src/Chroma/Chroma.csproj |
Bumps the provider version. |
Directory.Packages.props |
Updates ChromaDotNet.Client to 2.14.0. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
adamsitnik
approved these changes
Oct 14, 2026
adamsitnik
left a comment
adamsitnik
left a comment
Contributor
There was a problem hiding this comment.
LGTM, thank you for your contribution @Laurianti !
Contributor
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #58.
Fixes
#or$, like[VectorStoreData(StorageName = "#id")]. Chroma rejects these metadata keys, and uses the#ones, like#idand#document, in its Search API. Before, the collection was created, a write with a value failed on Chroma 1.5.9 and Chroma Cloud with "Invalid metadata at index 0", and with#ida filter liker.Tag == "meta-a"matched the record whose key ismeta-a. Now the collection throwsNotSupportedExceptionwhen it is created.new int?[] { 1, 2 }.Contains(r.NullableInt)threwNotSupportedException: "Inline array elements must be constants", because the compiler converts each element toint?. Now it becomes{"NullableInt":{"$in":[1,2]}}, as a comparison with a nullable property does.Changes
Containsneeds at least 3 characters.Tests
#or a$inside a storage name is still accepted.chromadb/chroma:1.5.9, 225 passed on Chroma Cloud, as on main.