You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Different artifact type names across execution environments #7849
Have I specified the code to reproduce the issue (Yes, No): No
Environment in which the code is executed (e.g., Local(Linux/MacOS/Windows), - Linux local + Kubernetes
Interactive Notebook, Google Cloud, etc): Bare metal
Describe the current behavior
When producing an example artifact locally, the "type" is Examples. When producing the same thing where Kubeflow pipelines is the runner, the artifact type is tfx.Examples. This makes the usage of TFX more brittle.
Describe the expected behavior
Artifact types should be consistent across environments
Standalone code to reproduce the issue
Write a TFX pipeline, compile it to run on kfp v2, and look at what's in ml_metadata.
Providing a bare minimum test case or step(s) to reproduce the problem will
greatly help us to debug the issue. If possible, please share a link to
Colab/Jupyter/any notebook.
Name of your Organization (Optional)
Intuitive.ai
Other info / logs
Include any logs or source code that would be helpful to diagnose the problem.
If including tracebacks, please include the full traceback. Large logs and files
should be attached.
Hi @pritamdodeja , Thanks for reporting this and sharing the details.
We’ve received the issue and are taking a look. We’ll follow up here once we have more information or if we need any additional inputs.
Appreciate your patience.
Thank you for addressing this! What causes the prefixing with tfx. in this case? Is it possible to fix it so that this is a more general fix (e.g. instead of undoing tfx. after it's been created, can we make the artifact names consistent in the first place? ). At what stage is the prefix introduced? I would imagine the more oblivious kfp is of what we're doing, the better, so the dependency shouldn't be in that direction. It is possible I don't understand architecturally everything that's going on.
Activity
bharatjetti commentedon Jun 1, 2026
Hi @pritamdodeja , Thanks for reporting this and sharing the details.
We’ve received the issue and are taking a look. We’ll follow up here once we have more information or if we need any additional inputs.
Appreciate your patience.
pritamdodeja commentedon Jun 26, 2026
Thank you for addressing this! What causes the prefixing with tfx. in this case? Is it possible to fix it so that this is a more general fix (e.g. instead of undoing tfx. after it's been created, can we make the artifact names consistent in the first place? ). At what stage is the prefix introduced? I would imagine the more oblivious kfp is of what we're doing, the better, so the dependency shouldn't be in that direction. It is possible I don't understand architecturally everything that's going on.