Problem

In the Feast Python SDK, get_online_features resolves feature view names through _get_any_feature_view, which checks the registry tables in a fixed order:

1. Regular FeatureView
2. OnDemandFeatureView
3. StreamFeatureView

This means if a project registers both a regular FeatureView and a StreamFeatureView (or OnDemandFeatureView) sharing the same name, get_online_features will always return the regular feature view — even if the stream view is the one producing the freshest data.

Relevant code

SqlRegistry._get_any_feature_view (sql.py#L374-L409):

def _get_any_feature_view(self, name: str, project: str) -> BaseFeatureView:
    fv = self._get_object(table=feature_views, ...)
    if not fv:
        fv = self._get_object(table=on_demand_feature_views, ...)
    if not fv:
        fv = self._get_object(table=stream_feature_views, ...)
    return fv

proto_registry_utils.get_any_feature_view follows the same fixed-order pattern for the cached registry path.

Same pattern in FeatureStore.apply

During apply, the different feature view types are separated into independent lists (views_to_update, sfvs_to_update, odfvs_to_update) and applied independently — there is no cross-type uniqueness check on names.

Expected Behavior

feast apply should fail with a clear error if a feature view name collides across different feature view types (e.g., a FeatureView and a StreamFeatureView sharing the same name). This would prevent silent, hard-to-debug issues at serving time.

Proposed Solution

Add a validation step in FeatureStore.apply() (or _validate_feature_views) that collects all feature view names across FeatureView, OnDemandFeatureView, and StreamFeatureView, and raises a ValueError if any duplicates are found.

Implementation guidance

1. Where to add the check: In FeatureStore.apply() (feature_store.py#L770), after the objects are separated into views_to_update, sfvs_to_update, and odfvs_to_update (around line 849), add a cross-type name uniqueness validation.

2. What the check should do:

   • Collect all names from views_to_update, sfvs_to_update, and odfvs_to_update
   • Detect any duplicate names across these lists
   • Raise a clear ValueError listing the duplicated name(s) and which types collide

3. Alternatively or additionally, the _validate_feature_views method (feature_store.py#L560-L579) could be extended to include this cross-type check.

4. Tests: Add unit tests that verify apply raises an error when feature views of different types share the same name.

References

• Discussed in Feast Slack #feast-beginners: thread