rc/0.4.5 - #295
Merged
Merged
Conversation
`roar put … hf://` stamps the published artifact `source_type="hf"` (put_execution.py, since 0.4.2), the publish path's own allowlist has accepted `hf` since #35, and the receiver has accepted it since June. The validator applied to every primitive artifact registration never learned it: VALID_SOURCE_TYPES has not changed since the initial commit. Nothing surfaced the gap because the failure is quiet. A staged artifact that fails validation is skipped, not rejected -- its message is collected into a warnings list and registration continues -- so an HF publish uploaded the file, reported success, and silently dropped that artifact's source from the lineage. The row still looked green: the output was already registered as a local artifact during the traced step, and the download location rides on a scoped label rather than on source_type. Also derives the rejection message from the set instead of hardcoding it. The old text still read "must be 's3', 'gs', 'https', or None" and would have gone stale again on the next scheme. The test pins the validator's set against the publish path's, so a scheme cannot be half-added a third time. Verified against prod glaas-api on a real delegated publish: previously "Artifact 0 (...): source_type must be ... got 'hf'" followed by "Registration completed with errors"; now a clean publish, 7/7, lineage published. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
fix(registration): accept hf artifacts in the validator
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
2 participants
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.
Release candidate 0.4.5.
Contents
fix(registration): accept hf artifacts in the validator.roar put … hf://stampssource_type="hf"on the published artifact, but the validator applied to every primitive artifact registration did not accept it, so the artifact was skipped — quietly, inside a run that reported success — and its source dropped from the lineage. The publish path's own allowlist and glaas-api had both acceptedhffor months; onlycore/validation.pywas missed, and it had not changed since the initial commit.chore(release): bump version to 0.4.5Verification
Beyond CI, the fix was exercised end to end on a real delegated publish to Hugging Face against prod glaas-api, from a wheel built off this branch.
Before:
Artifact 0 (…): source_type must be 's3', 'gs', 'https', or None, got 'hf'→Registration completed with errors.After: clean publish,
Reproducibility 7/7,lineage saved on glaas.ai · 1 files · published to hf://…, job exit 0,lineagePublicationStatus: published.A new test pins
VALID_SOURCE_TYPESagainst the publish path's_VALID_REMOTE_SOURCE_TYPESso a scheme cannot be half-added again, and the rejection message is now derived from the set rather than hardcoded.Follow-up worth considering separately
A staged artifact that fails validation is dropped with
continueand a warning, so an artifact the operator explicitly asked to publish can vanish from a run that exits 0. That shape — a green run with a quietly incomplete record — is the one this campaign keeps getting caught by. Not changed here.