[cyberlife-coder]

Description

Part of #2302 (this PR does not close it).

Supersedes #2451, which cannot merge as it stands (non-conforming branch prefix and commit author). The original change is kept and extended with the review findings. #2451 stays open for its owner to close.

VelesDBVectorStore passed filter= to the binding's search_with_ef, which has no such argument, so the call raised a TypeError from inside the integration. It now raises a ValueError naming the unsupported combination.

Changes on top of #2451:

• similarity_search_with_ef documents Raises: ValueError (docstring, integrations/langchain/README.md, CHANGELOG). ef_search defaults to 64 there, so any call that passes a filter is refused. It already failed with the TypeError; use similarity_search_with_filter for a filtered search without an ef_search override.
• A false comment in _run_vector_search ("search_with_quality does not support combined filter+quality in the core engine yet") is replaced. The binding exposes no filtered quality search: Collection.search_with_quality takes no filter, SearchOptions has no quality field, and run_dense in crates/velesdb-core/src/database/gated_search.rs drops the quality profile when a filter is present (core has search_with_quality_and_bitmap, but the PyO3 binding does not expose it). Since search_quality was silently dropped when filter was given, that combination now raises the same explicit ValueError. No public method reaches it today (similarity_search_with_score takes no filter), so this guards internal callers. ef_search alongside search_quality is unchanged: ef_search wins, as in the core read gate, and the comment now says so.
• New tests/test_ef_search_filter_real_binding.py, guarded by pytest.importorskip("velesdb"), runs against the real binding: ValueError for ef_search + filter, plain ef_search and plain filter still work, a test pinning that the binding's search_with_ef / search_with_quality still have no filter parameter (it fails the day that changes, so the refusal gets lifted), quality + filter refused, plain quality works.
• The fake collection in test_core_feature_parity.py now mirrors the real search_with_ef signature (ef_search=128, keyword-only principal / tenant).

Known limitation (why #2302 stays open)

A filtered search that honours ef_search is not implemented here. A real fix needs:

1. a new core public API search_with_filter_and_ef;
2. run_dense in crates/velesdb-core/src/database/gated_search.rs to stop ignoring ef when a filter is present;
3. the PyO3 binding;
4. the .pyi stub;
5. a parity test.

Observation (not changed here)

integrations/llamaindex/src/llamaindex_velesdb/search_ops.py query_with_ef accepts **kwargs documented as "reserved for future use", which silently swallows a mistaken filter=. That is the same bug class (a parameter dropped without notice); llamaindex is left untouched.

Type of Change

• 🐛 Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

• Unit tests

• Integration tests

• pytest integrations/langchain/tests: 217 passed, 2 skipped, 1 failed. The failure is test_e2e_complete.py::TestAsRetrieverE2E::test_as_retriever (VectorStoreRetriever has no get_relevant_documents with the installed langchain-core 1.7.0). It fails identically on origin/develop (208 passed, 2 skipped, 1 failed), so it is unrelated.

• scripts/check-doc-contract.sh, the five check-doc-freshness.py guards (strict), check-version-sync.py, check-mcp-doc-contract.py, check-promise-contract.py, check-feature-claims.py, check-python.sh and check-ai-attribution.py origin/develop..HEAD: all pass.

Test Configuration:

• OS: Linux
• Python 3.13, velesdb 6.0.0, langchain-core 1.7.0

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes (bar the unrelated failure above)
• Any dependent changes have been merged and published

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}