GeezerVison is showing github.com — when calling for several ODFVs at once, only fetches one ODFV's column-list per shared source view (last request wins), · Issue #6621 · feast-dev/feast
when calling for several ODFVs at once, only fetches one ODFV's column-list per shared source view (last request wins), #6621DescriptionExpected Behavior
When several on demand feature views share a source feature view but use different input columns, feature resolution should produce one entry for the shared source view whose projection contains the union of the required input columns.
Current Behavior
_get_feature_views_to_use appends the shared source view once per ODFV, each copy carrying only that ODFV's projection. The membership check if source_fv not in fvs_to_use never matches because BaseFeatureView.eq compares projections, and the freshly fetched view (full projection) never equals a stored narrowed copy. Downstream, _group_feature_refs keys its view index by projection.name_to_use(), so the last duplicate wins and the other ODFVs' source projections are silently dropped.
This corrupts get_historical_features output: with a request containing only ODFV refs, the losing ODFVs' input columns are never fetched, so transforms receive missing inputs (NaN in pandas mode). We hit this in production on 0.46, where a downstream fillna(0) turned the missing inputs into silently wrong feature values on about 10% of rows.
Since 0.62 the retrieval path is masked by the ref injection loop added in #6140, but the resolution helper still returns duplicate entries with conflicting projections to its other callers (_get_online_request_context, retrieve_online_documents, retrieve_online_documents_v2).
Steps to reproduce
src_fv = FeatureView(name="src_fv", entities=[driver], schema=[Field(name="a", dtype=Float64), Field(name="b", dtype=Float64)], source=...)
@on_demand_feature_view(sources=[src_fv[["a"]]], schema=[Field(name="a_out", dtype=Float64)], mode="pandas")
def odfv_a(inputs):
@on_demand_feature_view(sources=[src_fv[["b"]]], schema=[Field(name="b_out", dtype=Float64)], mode="pandas")
def odfv_b(inputs):
return pd.DataFrame({"b_out": inputs["b"] + 100})
fvs, _ = _get_feature_views_to_use(store.registry, store.project, ["odfv_a:a_out", "odfv_b:b_out"])
# Actual: two src_fv entries with projections ['a'] and ['b']
# Expected: one src_fv entry with projection ['a', 'b']
Specifications
- Version: master (also reproduced on 0.46; wrong retrieval values on 0.61 and earlier)
- Platform: all
- Subsystem: historical retrieval
Possible Solution
In _get_feature_views_to_use, match existing entries by projection.name_to_use() and merge projections (union of features, deduplicated by name) instead of appending a duplicate.
Related: #6099, #6140 Activitysanskar-singh-2403 commented on Jul 22, 2026 hey @addenergyx I'd like to take this one.
I traced it through on master and the diagnosis holds exactly:
-
In _get_feature_views_to_use (sdk/python/feast/utils.py), the per-ODFV loop over source_feature_view_projections.values() re-fetches the full-projection source_fv from the registry and guards it with if source_fv not in fvs_to_use.
-
That membership test goes through BaseFeatureView.eq, which compares self.projection != other.projection. The full-projection fetch never equals an already-stored narrowed copy, so the guard never matches and we append one src_fv duplicate per ODFV.
-
_group_feature_refs then keys view_index on projection.name_to_use(), the duplicates collide, and last-write-wins silently drops the other ODFVs' source projections.
The offline get_historical_features path is masked on 0.62+ by the ref-injection loop from #6140, but the online callers (_get_online_request_context, retrieve_online_documents, retrieve_online_documents_v2) still receive the conflicting duplicate entries.
Plan: in _get_feature_views_to_use, index accumulated source views by projection.name_to_use() and, on a repeat hit, merge the projections (union of features deduped by name) instead of appending a duplicate so a shared source view resolves to a single entry carrying the union of required input columns.
Tests: unit coverage for the resolver (two ODFVs sharing one source with disjoint input columns → one merged src_fv entry with projection ['a','b']), plus a get_historical_features regression asserting both ODFV inputs are fetched (no NaN/fillna corruption). Will also confirm the online-doc retrieval callers stay correct. added a commit that references this issue on Jul 22, 2026This issue will close once commit 621c1b1 is merged into the 'master' branch.621c1b1 addenergyx commented on Jul 22, 2026 ContributorAuthor More actions Reacted by Sanskar Singh Bhardwaj sanskar-singh-2403 commented on Jul 22, 2026 @addenergyx i also opened a PR for you to check it once in the code as well sanskar-singh-2403 commented on Jul 25, 2026 added a commit that references this issue on Jul 25, 2026This issue will close once commit ea94468 is merged into the 'master' branch.ea94468 added 3 commits that reference this issue on Jul 30, 2026This issue will close once commit b4feda7 is merged into the 'master' branch.b4feda7 This issue will close once commit da47014 is merged into the 'master' branch.da47014 This issue will close once commit d269946 is merged into the 'master' branch.d269946 addenergyx commented on Jul 31, 2026 ContributorAuthor More actions Thank you all for the quick fix! Reacted by Sanskar Singh Bhardwaj
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|