Open
Conversation
Keep mlflow.artifactLocation reserved for trace artifacts and attachments, and document a separate archive-location tag for archived traces so archival does not break attachment reads.
mprahl
approved these changes
Apr 7, 2026
Collaborator
mprahl
left a comment
There was a problem hiding this comment.
I think this makes sense and I don't see an alternative such as archiving the attachments in the trace archival either because the artifact repository can be user provided.
Collaborator
|
@B-Step62 could you please take a look? |
31 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This updates the trace archival RFC to keep
mlflow.artifactLocationas the existing trace artifact root and to introduce a separate tag for archived traces.pb payloads.The main reason for the change is that
mlflow.artifactLocationalready does more than point to trace JSON. It is also the location used for trace attachments. If we repoint that tag during archival, archived traces would start looking for attachments in the archive repo, even though those files were never moved there. That would make attachment reads fail unless archival also copied attachment files over.I considered that alternative, but it adds extra work and more failure cases to the archival flow. Archival would need to discover, copy, and validate attachments before updating the trace location, and it would need to stay safe and retryable if part of that process failed. That is a lot of extra complexity for something we do not actually need.
Using a separate archive-location tag is simpler and safer. It preserves the current meaning of
mlflow.artifactLocation, keeps existing attachment behavior intact, and makes the archived span payload location explicit. It also keeps the retrieval logic easier to understand: regular trace artifacts and attachments continue to use the existing tag, while archived span payloads use the new one.Here's an example script illustrating the point:
attachments_example.py