Skip to content

fix: correct project_id scoping in get_user_metadata and delete_project#6248

Open
Abhishek8108 wants to merge 1 commit intofeast-dev:masterfrom
Abhishek8108:fix/snowflake-registry-project-id-scoping
Open

fix: correct project_id scoping in get_user_metadata and delete_project#6248
Abhishek8108 wants to merge 1 commit intofeast-dev:masterfrom
Abhishek8108:fix/snowflake-registry-project-id-scoping

Conversation

@Abhishek8108
Copy link
Copy Markdown

@Abhishek8108 Abhishek8108 commented Apr 8, 2026

Summary

Two pre-existing SQL correctness bugs in SnowflakeRegistry, noticed while working on #6243.

get_user_metadata (line 1119)
The SELECT query filtered only by {fv_column_name}_name, without scoping to project_id. The primary key for feature view tables is (feature_view_name, project_id), so in a shared Snowflake registry this could return user metadata from a different project's feature view with the same name. Fixed by adding project_id = '{project}' to the WHERE clause — consistent with apply_user_metadata which already does this correctly.

delete_project (line 1326)
The DELETE query interpolated project, which is a Project object returned by self.get_project(name). Project.__str__ returns str(MessageToJson(self.to_proto())) — a JSON blob — which never matches any project_id stored in the database. This made delete_project a silent no-op: all DELETE statements executed successfully but matched zero rows. Fixed by using the name string parameter directly.

Testing

Both are SQL correctness fixes. The existing integration test suite in test_universal_registry.py covers both methods end-to-end; no new unit test surface is introduced by these changes.

Relates to #6243.

get_user_metadata was filtering only by feature view name, allowing a
shared Snowflake registry to return user metadata from a different
project's feature view with the same name. Added project_id = '{project}'
to the WHERE clause, consistent with apply_user_metadata.

delete_project was interpolating a Project object into the SQL string
instead of the project name string, which would use __str__ of the object
rather than the actual name. Changed to use the `name` parameter directly.

Signed-off-by: Abhishek8108 <[email protected]>
@Abhishek8108 Abhishek8108 requested a review from a team as a code owner April 8, 2026 20:49
Copy link
Copy Markdown
Contributor

@devin-ai-integration devin-ai-integration bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 3 additional findings.

Open in Devin Review

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant