Fix: Scope feature view name conflict checks by project in file registry#6210
Fix: Scope feature view name conflict checks by project in file registry#6210SARAMALI15792 wants to merge 1 commit intofeast-dev:masterfrom
Conversation
The file-based registry was incorrectly checking for feature view name conflicts across all projects in a shared registry, causing false positives when different projects used the same feature view names. This fix replaces the custom conflict checking logic with the base class method _ensure_feature_view_name_is_unique, which properly scopes checks by project. This aligns the file registry behavior with the SQL registry implementation. Changes: - Use _ensure_feature_view_name_is_unique from BaseRegistry (same as SQL registry) - Remove _check_conflicting_feature_view_names and _existing_feature_view_names_to_fvs methods - Add regression test for cross-project feature view names Fixes feast-dev#6209
| assert self.cached_registry_proto | ||
|
|
||
| self._check_conflicting_feature_view_names(feature_view) | ||
| self._ensure_feature_view_name_is_unique(feature_view, project) |
There was a problem hiding this comment.
🔴 Cache overwrite in file registry causes loss of uncommitted changes during batch apply
The new _ensure_feature_view_name_is_unique (defined at sdk/python/feast/infra/registry/base_registry.py:277) calls getter methods like self.get_feature_view(name, project, allow_cache=False). In the file registry, these getters call _get_registry_proto(project, allow_cache=False) (sdk/python/feast/infra/registry/registry.py:1292), which when allow_cache=False always re-reads from the store and overwrites self.cached_registry_proto at line 1343. This discards any uncommitted in-memory changes.
The old method _check_conflicting_feature_view_names only read from self.cached_registry_proto directly without triggering a store re-read, so it preserved uncommitted state.
This is triggered in feature_store.py:1199-1202 where apply_feature_view is called in a loop with commit=False after other uncommitted apply_project and apply_data_source calls. The first apply_feature_view call's uniqueness check overwrites the cache, losing all prior uncommitted projects and data sources. The second call loses the first feature view, and so on.
Triggering call site in feature_store.py
for view in itertools.chain(views_to_update, odfvs_to_update, sfvs_to_update):
self.registry.apply_feature_view(
view, project=self.project, commit=False, no_promote=no_promote
)Prompt for agents
In sdk/python/feast/infra/registry/registry.py at line 758, the call to self._ensure_feature_view_name_is_unique(feature_view, project) uses allow_cache=False (the default), which causes the getter methods inside it to re-read from the registry store and overwrite self.cached_registry_proto, discarding uncommitted changes.
The fix should either:
1. Pass allow_cache=True to _ensure_feature_view_name_is_unique so the getters use the cached proto instead of re-reading from the store: self._ensure_feature_view_name_is_unique(feature_view, project, allow_cache=True)
2. Or, override _ensure_feature_view_name_is_unique in the file Registry class to check the in-memory cached_registry_proto directly (similar to the old _check_conflicting_feature_view_names approach), avoiding any calls to _get_registry_proto.
Option 1 is the simplest fix. The cache is already prepared by _prepare_registry_for_changes at line 755, so allow_cache=True is safe and appropriate here.
Was this helpful? React with 👍 or 👎 to provide feedback.
Fixes #6209
Summary
The file-based registry was incorrectly checking for feature view name conflicts across all projects in a shared registry, causing false positives when different projects used the same feature view names.
Problem
When using a shared file-based registry with multiple projects, the registry would raise ConflictingFeatureViewNames errors even when different projects used the same feature view names (which should be allowed since projects are separate namespaces).
Example:
Solution
Replace the custom conflict checking logic with the base class method _ensure_feature_view_name_is_unique, which properly scopes checks by project. This aligns the file registry behavior with the SQL registry implementation.
Changes
Test Plan
Fixes #6209