Skip to content

fix: use a distinct source URI for the FP pipeline version context - #6540

Open
pravali96 wants to merge 1 commit into
aws:masterfrom
pravali96:fp-pipeline-version-source-uri-v3
Open

pravali96 wants to merge 1 commit into
aws:masterfrom
pravali96:fp-pipeline-version-source-uri-v3

Conversation

@pravali96

Copy link
Copy Markdown
Collaborator

Feature Processor created both the pipeline context and the pipeline version context with the pipeline ARN as their source URI. Consumers that key lineage graph nodes on source URI therefore collapsed the two contexts into a single node, and could not tell successive versions apart.

Append the version key already passed to create_pipeline_version_context to the version context's source URI, so every version gets a URI distinct from the pipeline's and from other versions. The last update time is what already identifies a version throughout this module: it names the context and is stored as source_type and in properties["LastUpdateTime"].

SageMaker's own PipelineVersionId was not used because DescribePipeline, the only pipeline call Feature Processor makes, does not return it; reading it would add a ListPipelineVersions call to the lineage path and require that permission for all Feature Processor users.

Reads are unaffected: load_pipeline_version_context resolves contexts by name, not by source URI. Contexts created before this change keep their old source URI.

Issue #, if available:

Description of changes:

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Feature Processor created both the pipeline context and the pipeline
version context with the pipeline ARN as their source URI. Consumers that
key lineage graph nodes on source URI therefore collapsed the two contexts
into a single node, and could not tell successive versions apart.

Append the version key already passed to create_pipeline_version_context
to the version context's source URI, so every version gets a URI distinct
from the pipeline's and from other versions. The last update time is what
already identifies a version throughout this module: it names the context
and is stored as source_type and in properties["LastUpdateTime"].

SageMaker's own PipelineVersionId was not used because DescribePipeline,
the only pipeline call Feature Processor makes, does not return it;
reading it would add a ListPipelineVersions call to the lineage path and
require that permission for all Feature Processor users.

Reads are unaffected: load_pipeline_version_context resolves contexts by
name, not by source URI. Contexts created before this change keep their
old source URI.
@pravali96
pravali96 marked this pull request as ready for review October 28, 2026 18:32
@pravali96
pravali96 deployed to auto-approve October 28, 2026 19:32 — with GitHub Actions Active
@pravali96
pravali96 deployed to auto-approve October 28, 2026 19:32 — with GitHub Actions Active
@pravali96
pravali96 deployed to auto-approve October 28, 2026 19:33 — with GitHub Actions Active

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🤖 AI code review

This PR fixes a lineage bug where the Feature Processor pipeline version context and the pipeline context shared the same source_uri (the pipeline ARN), causing consumers that key graph nodes on source URI to collapse distinct versions into one node. It appends the last_update_time version key to the version context's source URI so each version gets a distinct URI, and updates the two affected unit test fixtures to match. Reads resolve version contexts by name (load_pipeline_version_context), so this is backward compatible, as the PR describes. The change is small, correct, and adequately covered by the updated tests; no issues found.

Reviewed commit a0c2393. Automated review; verify before acting.

This branch was successfully deployed

1 active deployment
auto-approve — a0c23931 Deployed Oct 28, 2026 by pravali96 via wait-for-approval #769
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.

3 participants