Repository navigation
fix: use a distinct source URI for the FP pipeline version context - #6540
Conversation
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.
There was a problem hiding this comment.
🤖 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.
There was a problem hiding this comment.
🤖 AI code review
This PR fixes Feature Processor lineage by appending the version key (last_update_time) to the pipeline version context's source_uri, so it no longer collides with the pipeline context's URI (both were the pipeline ARN). I verified the load path (load_pipeline_version_context) resolves contexts by name, and no code keys lookups on the version context's source_uri, so the change is backward compatible. The two affected unit test expectations are updated to match. The change is minimal, correct, and well-scoped; no issues found.
Reviewed commit 8bc695c. Automated review; verify before acting.
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.