we should deprecate the retrieve-online-documents API and rename it as search API to highlight the more generic primitive we want to support, which will offer a lot more long term flexibility.

CC @ntkathole

Okay I have added the new endpoint /search and deprecated the retrieve-online-documents as it is still available for the backward compatibility.

yeah this seems acceptable if it's opt-in but we should also support sentence transformers.

i think there's a bug here: this new endpoint bypasses _get_features, so auth-enabled servers never run the existing READ_ONLINE check for the target feature view. /search goes through _get_features() before retrieval, but this path calls store.retrieve_online_documents_openai(...) directly. Can we resolve the feature view, assert AuthzedAction.READ_ONLINE, and add an auth regression test for this endpoint?

Okay I will add those test as well as the authentication checks for this newly added api endpoints

Auth regression test is out of scope for this PR, will address in a follow-up

i think this is returning the wrong OpenAI semantics. distance is lower-is-better for the default pgvector L2 path, but the OpenAI response field is score, which clients treat as higher-is-better relevance and use with score_threshold. We should either normalize per metric before putting it in score, or avoid claiming OpenAI score semantics here.

Added _distance_to_score(distance, metric) in utils.py and applied it at the store level in Postgres, SQLite, and Milvus. Elasticsearch and Qdrant already return higher-is-better scores, so no changes needed there

This accepts and forwards ranking_options, including score_threshold, but retrieve_online_documents_openai() never applies it. That makes clients think thresholding is enforced when it is silently ignored. Can we either implement score_threshold now or reject unsupported ranking_options/rewrite_query with a 4xx until they are wired?

This still mutates the caller-owned requested_features list. When this is called through FeatureStore._retrieve_from_online_store_v2, Feast later builds features_to_request = requested_features + ["distance"], so distance can appear twice in the response metadata. Please copy before appending, or keep synthetic fields owned by one layer only.

By default this requests every feature from the feature view, which includes the embedding/vector field itself. The response conversion below then copies every non-entity, non-distance field into attributes, so OpenAI-compatible search responses can include the raw embedding vector as metadata. Can we exclude vector fields by default and only return scalar metadata/content fields unless explicitly requested?

Sure, I remove the vector field from the feature_names

This doc says string equality filters work on all backends without the new store flag, but the Postgres and SQLite implementations reject any filter when enable_openai_compatible_store is false. Either the runtime should allow text-only filters on existing schemas, or the docs should say all filtering requires the flag for those backends.

but this isn't openai compatible.

I initially went with feature view names for simplicity from implementation and user perspective but you're right it should follow the OpenAI vs_{hash} format for proper compatibility.

it is an easy addition, plan is to hash the project:feature_view_name and cache it at server startup time and it refresh at every registry TTL, Will also add GET /v1/vector_stores so user can discover the vs_ IDs for their feature views

working on it

Now added this endpoint Give it another look when you get time

the product_catalog is not vector store compatible. it should be some vs_{hash} identifier.

i think this fix landed in the wrong layer. retrieve_online_documents_v2() and /search still expose this synthetic field as distance, but Postgres now stores a higher-is-better OpenAI score in it. That changes the native Feast contract for non-OpenAI callers, and the same pattern appears in SQLite/Milvus. Can we keep the stores returning raw distances and convert to OpenAI score only in retrieve_online_documents_openai()?

this rejects rewrite_query: false, even though that is the no-op/default shape an OpenAI-compatible client can send. OGX keeps this field for API compatibility and ignores false at the store layer. Can we only reject rewrite_query=True until query rewriting is implemented?

the docs now say ranking_options and rewrite_query are accepted but not applied, but the implementation raises 422 when score_threshold, ranker, or any rewrite_query value is present. Can we make the docs match the actual behavior, or wire the supported no-op/default cases?

i'm a little worried about requiring litellm for embeddings, why wouldn't we embed within feast? in fact, i think this is a good usage of this. even though it's not as efficient as using a GPU, it's good enough.

CC @ntkathole

We want to support wide range of the embedding model and using litellm for embedding looks feasible option to me but in feast we support the sentence-transformers for doing it entirely in the feast.

yeah so then let's not add litellm to scope

are we limiting this only to vector search? or are we supporting hybrid as well?

Currently we are doing only the vector search

[Critical] SQL Injection vulnerability in Milvus string escaping

The Milvus string escaping function only escapes backslashes and single quotes, but doesn't handle other potential injection vectors. Milvus boolean expressions could be vulnerable to injection if field names or other components aren't properly validated.

Suggested: