fix: Check duplicate names for feature view across types by Prathap-P · Pull Request #5999 · feast-dev/feast

Prathap-P · 2026-02-21T12:10:46Z

What this PR does / why we need it:

This PR enforces cross-type feature view name uniqueness to fix a bug (Enforce unique feature view names across all feature view types during apply #5995).
Previously, get_online_features resolved feature view names via get_any_feature_view, which checks registry tables in a fixed order: FeatureView → StreamFeatureView → OnDemandFeatureView.
If a project registered both a FeatureView and StreamFeatureView with the same name, every get_online_features call would silently return the FeatureView, even when the StreamFeatureView contained fresher data

Which issue(s) this PR fixes:

Fixes #5995

Misc

HaoXuAI · 2026-02-22T16:27:13Z

sdk/python/feast/infra/registry/base_registry.py

+
+        # Check StreamFeatureView before FeatureView since StreamFeatureView is a subclass
+        # Note: All getters raise FeatureViewNotFoundException (not type-specific exceptions)
+        if isinstance(feature_view, StreamFeatureView):


Does this mean it will call to retrieve feature view many times? Can we optimize it?

If I understand correctly, you're concerned that when creating 100 feature views, the apply_feature_view function calls the getters for the other two types each time. That results in 2 database calls per feature view — 200 total — and you’re wondering if we should optimize this part.

@HaoXuAI
I have a plan. We need to validate in two places:

In the incoming request — ensure the new feature view name doesn’t exist in the other two types within the request (and vice versa).

In the database — check against existing records (for the SQL registry case).

Currently, the cache util doesn’t have an exists function to check if a name is already in the registry. Even if it did, calling it 100 times wouldn’t be efficient.

So I’m planning to create a util function per feature view type that takes a list of names and a project, and checks that none of the names exist in the DB.

For example, if 50 feature views come in:

I’ll call the new util once with those 50 names against the stream and on-demand tables.

Do the same vice versa for the other types.

This way, instead of calling per feature view, we make only two DB calls per type.

That’s my current idea. Do you see any better optimization?

@HaoXuAI I can go ahead to implement, if you find we are good with above logic 😄

i think that makes sense. Feel free to create a new issue for this. We can go with the current solution for now

ntkathole · 2026-02-28T16:13:45Z

sdk/python/feast/feature_store.py

-                f"More than one feature view with name {case_insensitive_fv_name} found. "
-                f"Please ensure that all feature view names are case-insensitively unique. "
-                f"It may be necessary to ignore certain files in your feature repository by using a .feastignore file."
+        if case_insensitive_fv_name in fv_by_name:


_validate_feature_views() in feature_store.py uses case-insensitive names (fv.name.lower()), while
_ensure_feature_view_name_is_unique() relies on the registry getters, which are typically case-sensitive. Worth aligning the behavior.

@ntkathole Thanks for your comment.
On trying to work on that, I have a found an inconsistency (might be a potential issue).
I'm holding my progress on above issue, till I get clarified on this.

In current Feast master, FeatureStore.apply() behaves as an incremental upsert (not a full registry refresh): it validates only the objects in the current request and writes those objects, while existing unrelated records remain untouched. Because of this, duplicate-name protection is incomplete for previously registered objects—especially when names differ only by case (for example, existing driver and new Driver). The in-request validation checks only the incoming payload, and the SQL registry uniqueness constraints are per table and case-sensitive by default, so this scenario can pass and create ambiguous registry state. Expected behavior (per my understanding) is case-insensitive uniqueness for feature view names, so this appears to be a gap.

@Prathap-P I think it's fine if you want to handle it separately and we keep scope of this PR for sql registry duplicate names

@ntkathole Solving the test cases took a lot of time, finally was able to fix it. Do you have any other points to discuss?

I know Devin is reporting these changes are not implemented in snowflake, but as you said to scope this pr to sql, ignoring it...

devin-ai-integration

Devin Review found 1 new potential issue.

🐛 1 issue in files not directly in the diff

🐛 Cross-type uniqueness check missing from SnowflakeRegistry.apply_feature_view (`sdk/python/feast/infra/registry/snowflake.py:261-272`)

The PR adds _ensure_feature_view_name_is_unique to BaseRegistry and calls it from SqlRegistry.apply_feature_view (sdk/python/feast/infra/registry/sql.py:580), but the same call is missing from SnowflakeRegistry.apply_feature_view (sdk/python/feast/infra/registry/snowflake.py:261-272). This means the "defense-in-depth" cross-type name conflict check is not enforced when users use the Snowflake registry and directly call apply_feature_view.

Incomplete application of fix across registry implementations

The SnowflakeRegistry.apply_feature_view at sdk/python/feast/infra/registry/snowflake.py:261-272 does not call self._ensure_feature_view_name_is_unique(feature_view, project) before applying the feature view:

def apply_feature_view(
    self, feature_view: BaseFeatureView, project: str, commit: bool = True
):
    fv_table_str = self._infer_fv_table(feature_view)
    fv_column_name = fv_table_str[:-1]
    return self._apply_object(...)

Compare with the updated SqlRegistry.apply_feature_view at sdk/python/feast/infra/registry/sql.py:577-585 which does call it:

def apply_feature_view(
    self, feature_view: BaseFeatureView, project: str, commit: bool = True
):
    self._ensure_feature_view_name_is_unique(feature_view, project)  # added
    fv_table = self._infer_fv_table(feature_view)
    ...

Impact: Snowflake registry users who directly call apply_feature_view (bypassing feast apply) can still register a FeatureView and a StreamFeatureView with the same name, leading to the same silent data correctness bug (issue #5995) that this PR intends to fix.

View 8 additional findings in Devin Review.

devin-ai-integration

Devin Review found 1 new potential issue.

🐛 1 issue in files not directly in the diff

🐛 Cross-type uniqueness check missing from SnowflakeRegistry.apply_feature_view (`sdk/python/feast/infra/registry/snowflake.py:261-272`)

The PR adds _ensure_feature_view_name_is_unique to BaseRegistry and calls it from SqlRegistry.apply_feature_view (sdk/python/feast/infra/registry/sql.py:580), but the same call is missing from SnowflakeRegistry.apply_feature_view (sdk/python/feast/infra/registry/snowflake.py:261-272). This means the "defense-in-depth" cross-type name conflict check is not enforced when users use the Snowflake registry and directly call apply_feature_view.

Incomplete application of fix across registry implementations

The SnowflakeRegistry.apply_feature_view at sdk/python/feast/infra/registry/snowflake.py:261-272 does not call self._ensure_feature_view_name_is_unique(feature_view, project) before applying the feature view:

def apply_feature_view(
    self, feature_view: BaseFeatureView, project: str, commit: bool = True
):
    fv_table_str = self._infer_fv_table(feature_view)
    fv_column_name = fv_table_str[:-1]
    return self._apply_object(...)

Compare with the updated SqlRegistry.apply_feature_view at sdk/python/feast/infra/registry/sql.py:577-585 which does call it:

def apply_feature_view(
    self, feature_view: BaseFeatureView, project: str, commit: bool = True
):
    self._ensure_feature_view_name_is_unique(feature_view, project)  # added
    fv_table = self._infer_fv_table(feature_view)
    ...

Impact: Snowflake registry users who directly call apply_feature_view (bypassing feast apply) can still register a FeatureView and a StreamFeatureView with the same name, leading to the same silent data correctness bug (issue #5995) that this PR intends to fix.

View 10 additional findings in Devin Review.

devin-ai-integration

Devin Review found 1 new potential issue.

🐛 1 issue in files not directly in the diff

🐛 Cross-type uniqueness check missing from SnowflakeRegistry.apply_feature_view (`sdk/python/feast/infra/registry/snowflake.py:261-272`)

The PR adds _ensure_feature_view_name_is_unique to BaseRegistry and calls it from SqlRegistry.apply_feature_view (sdk/python/feast/infra/registry/sql.py:580), but the same call is missing from SnowflakeRegistry.apply_feature_view (sdk/python/feast/infra/registry/snowflake.py:261-272). This means the "defense-in-depth" cross-type name conflict check is not enforced when users use the Snowflake registry and directly call apply_feature_view.

Incomplete application of fix across registry implementations

The SnowflakeRegistry.apply_feature_view at sdk/python/feast/infra/registry/snowflake.py:261-272 does not call self._ensure_feature_view_name_is_unique(feature_view, project) before applying the feature view:

def apply_feature_view(
    self, feature_view: BaseFeatureView, project: str, commit: bool = True
):
    fv_table_str = self._infer_fv_table(feature_view)
    fv_column_name = fv_table_str[:-1]
    return self._apply_object(...)

Compare with the updated SqlRegistry.apply_feature_view at sdk/python/feast/infra/registry/sql.py:577-585 which does call it:

def apply_feature_view(
    self, feature_view: BaseFeatureView, project: str, commit: bool = True
):
    self._ensure_feature_view_name_is_unique(feature_view, project)  # added
    fv_table = self._infer_fv_table(feature_view)
    ...

Impact: Snowflake registry users who directly call apply_feature_view (bypassing feast apply) can still register a FeatureView and a StreamFeatureView with the same name, leading to the same silent data correctness bug (issue #5995) that this PR intends to fix.

View 13 additional findings in Devin Review.

devin-ai-integration

Devin Review found 1 new potential issue.

🐛 1 issue in files not directly in the diff

🐛 Cross-type uniqueness check missing from SnowflakeRegistry.apply_feature_view (`sdk/python/feast/infra/registry/snowflake.py:261-272`)

The PR adds _ensure_feature_view_name_is_unique to BaseRegistry and calls it from SqlRegistry.apply_feature_view (sdk/python/feast/infra/registry/sql.py:580), but the same call is missing from SnowflakeRegistry.apply_feature_view (sdk/python/feast/infra/registry/snowflake.py:261-272). This means the "defense-in-depth" cross-type name conflict check is not enforced when users use the Snowflake registry and directly call apply_feature_view.

Incomplete application of fix across registry implementations

The SnowflakeRegistry.apply_feature_view at sdk/python/feast/infra/registry/snowflake.py:261-272 does not call self._ensure_feature_view_name_is_unique(feature_view, project) before applying the feature view:

def apply_feature_view(
    self, feature_view: BaseFeatureView, project: str, commit: bool = True
):
    fv_table_str = self._infer_fv_table(feature_view)
    fv_column_name = fv_table_str[:-1]
    return self._apply_object(...)

Compare with the updated SqlRegistry.apply_feature_view at sdk/python/feast/infra/registry/sql.py:577-585 which does call it:

def apply_feature_view(
    self, feature_view: BaseFeatureView, project: str, commit: bool = True
):
    self._ensure_feature_view_name_is_unique(feature_view, project)  # added
    fv_table = self._infer_fv_table(feature_view)
    ...

Impact: Snowflake registry users who directly call apply_feature_view (bypassing feast apply) can still register a FeatureView and a StreamFeatureView with the same name, leading to the same silent data correctness bug (issue #5995) that this PR intends to fix.

View 12 additional findings in Devin Review.

devin-ai-integration

Devin Review found 1 new potential issue.

🐛 1 issue in files not directly in the diff

🐛 Cross-type uniqueness check missing from SnowflakeRegistry.apply_feature_view (`sdk/python/feast/infra/registry/snowflake.py:261-272`)

The PR adds _ensure_feature_view_name_is_unique to BaseRegistry and calls it from SqlRegistry.apply_feature_view (sdk/python/feast/infra/registry/sql.py:580), but the same call is missing from SnowflakeRegistry.apply_feature_view (sdk/python/feast/infra/registry/snowflake.py:261-272). This means the "defense-in-depth" cross-type name conflict check is not enforced when users use the Snowflake registry and directly call apply_feature_view.

Incomplete application of fix across registry implementations

The SnowflakeRegistry.apply_feature_view at sdk/python/feast/infra/registry/snowflake.py:261-272 does not call self._ensure_feature_view_name_is_unique(feature_view, project) before applying the feature view:

def apply_feature_view(
    self, feature_view: BaseFeatureView, project: str, commit: bool = True
):
    fv_table_str = self._infer_fv_table(feature_view)
    fv_column_name = fv_table_str[:-1]
    return self._apply_object(...)

Compare with the updated SqlRegistry.apply_feature_view at sdk/python/feast/infra/registry/sql.py:577-585 which does call it:

def apply_feature_view(
    self, feature_view: BaseFeatureView, project: str, commit: bool = True
):
    self._ensure_feature_view_name_is_unique(feature_view, project)  # added
    fv_table = self._infer_fv_table(feature_view)
    ...

Impact: Snowflake registry users who directly call apply_feature_view (bypassing feast apply) can still register a FeatureView and a StreamFeatureView with the same name, leading to the same silent data correctness bug (issue #5995) that this PR intends to fix.

View 13 additional findings in Devin Review.

ntkathole

Thanks @Prathap-P

Signed-off-by: Prathap P <436prathap@gmail.com>

Prathap-P requested a review from a team as a code owner February 21, 2026 12:10

This comment was marked as resolved.

Sign in to view

Prathap-P force-pushed the featureview_name_collision branch 4 times, most recently from 77cc24c to c299a71 Compare February 21, 2026 13:19

Prathap-P changed the title ~~check duplicate names for feature view across types~~ fix: check duplicate names for feature view across types Feb 21, 2026

Prathap-P changed the title ~~fix: check duplicate names for feature view across types~~ fix: Check duplicate names for feature view across types Feb 21, 2026

HaoXuAI reviewed Feb 22, 2026

View reviewed changes

Prathap-P requested a review from HaoXuAI February 24, 2026 16:21

HaoXuAI approved these changes Feb 28, 2026

View reviewed changes

HaoXuAI added the ok-to-test label Feb 28, 2026

ntkathole force-pushed the featureview_name_collision branch from 3d8682d to 0332891 Compare February 28, 2026 15:36

ntkathole reviewed Feb 28, 2026

View reviewed changes

Prathap-P force-pushed the featureview_name_collision branch from 4c5be75 to a2a0e29 Compare March 1, 2026 17:30

This comment was marked as resolved.

Sign in to view

Prathap-P force-pushed the featureview_name_collision branch 2 times, most recently from c2acd43 to 7404904 Compare March 2, 2026 14:05

This comment was marked as resolved.

Sign in to view

Prathap-P force-pushed the featureview_name_collision branch from 786b948 to 86781e9 Compare March 3, 2026 10:02

devin-ai-integration bot reviewed Mar 3, 2026

View reviewed changes

Prathap-P force-pushed the featureview_name_collision branch from d2972de to c299a71 Compare March 4, 2026 11:24

devin-ai-integration bot reviewed Mar 4, 2026

View reviewed changes

Prathap-P force-pushed the featureview_name_collision branch from b7e9e68 to eac7fe0 Compare March 6, 2026 06:01

devin-ai-integration bot reviewed Mar 6, 2026

View reviewed changes

ntkathole approved these changes Mar 6, 2026

View reviewed changes

Prathap-P added 5 commits March 6, 2026 17:33

check duplicate names for feature view across types

6e256b6

Signed-off-by: Prathap P <436prathap@gmail.com>

fix: check uniqueness before applying feature view

e319a6f

Signed-off-by: Prathap P <436prathap@gmail.com>

use FeatureViewNotFoundException for all types as per Devin's suggestion

be0e8a3

Signed-off-by: Prathap P <436prathap@gmail.com>

fix tests

8363cd4

Signed-off-by: Prathap P <436prathap@gmail.com>

fix linting issues

d7bac33

Signed-off-by: Prathap P <436prathap@gmail.com>

ntkathole force-pushed the featureview_name_collision branch from 7a20e7b to d7bac33 Compare March 6, 2026 12:03

ntkathole merged commit 95b9af8 into feast-dev:master Mar 6, 2026
20 of 26 checks passed

Conversation

Prathap-P commented Feb 21, 2026 • edited by devin-ai-integration bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What this PR does / why we need it:

Which issue(s) this PR fixes:

Misc

Uh oh!

This comment was marked as resolved.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Prathap-P Mar 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment was marked as resolved.

Uh oh!

This comment was marked as resolved.

Uh oh!

This comment was marked as resolved.

Uh oh!

This comment was marked as resolved.

Uh oh!

devin-ai-integration bot left a comment

Choose a reason for hiding this comment

🐛 Cross-type uniqueness check missing from SnowflakeRegistry.apply_feature_view (sdk/python/feast/infra/registry/snowflake.py:261-272)

Uh oh!

devin-ai-integration bot left a comment

Choose a reason for hiding this comment

🐛 Cross-type uniqueness check missing from SnowflakeRegistry.apply_feature_view (sdk/python/feast/infra/registry/snowflake.py:261-272)

Uh oh!

devin-ai-integration bot left a comment

Choose a reason for hiding this comment

🐛 Cross-type uniqueness check missing from SnowflakeRegistry.apply_feature_view (sdk/python/feast/infra/registry/snowflake.py:261-272)

Uh oh!

devin-ai-integration bot left a comment

Choose a reason for hiding this comment

🐛 Cross-type uniqueness check missing from SnowflakeRegistry.apply_feature_view (sdk/python/feast/infra/registry/snowflake.py:261-272)

Uh oh!

devin-ai-integration bot left a comment

Choose a reason for hiding this comment

🐛 Cross-type uniqueness check missing from SnowflakeRegistry.apply_feature_view (sdk/python/feast/infra/registry/snowflake.py:261-272)

Uh oh!

ntkathole left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Prathap-P commented Feb 21, 2026 •

edited by devin-ai-integration bot

Loading

Prathap-P Mar 6, 2026 •

edited

Loading

🐛 Cross-type uniqueness check missing from SnowflakeRegistry.apply_feature_view (`sdk/python/feast/infra/registry/snowflake.py:261-272`)

🐛 Cross-type uniqueness check missing from SnowflakeRegistry.apply_feature_view (`sdk/python/feast/infra/registry/snowflake.py:261-272`)

🐛 Cross-type uniqueness check missing from SnowflakeRegistry.apply_feature_view (`sdk/python/feast/infra/registry/snowflake.py:261-272`)

🐛 Cross-type uniqueness check missing from SnowflakeRegistry.apply_feature_view (`sdk/python/feast/infra/registry/snowflake.py:261-272`)

🐛 Cross-type uniqueness check missing from SnowflakeRegistry.apply_feature_view (`sdk/python/feast/infra/registry/snowflake.py:261-272`)