Summary #
Multiple artifact records can exist in the owner's PDS for the same repository, annotated tag, and artifact name, while the repository UI shows only one of them.
Observed case #
Repository: https://tangled.org/nnabeyang.tngl.sh/spindle-agent
Tag: 0.1.1
Artifact name: spa-0.1.1-macos-arm64.tar.gz
The owner's PDS contains both records:
at://did:plc:jge3zxi7lgrfnvhzcgrimeo7/sh.tangled.repo.artifact/3msttflvyvz22at://did:plc:jge3zxi7lgrfnvhzcgrimeo7/sh.tangled.repo.artifact/3mstv4owbfb22
Both records refer to the annotated tag object 72b818b3978861c6d0a73deaf8313d989342e0db, have the same artifact name, and currently reference the same blob. Only one artifact is visible in the repository UI.
Expected behavior #
The UI and indexed artifact state should not silently omit a valid PDS record. If duplicate names are intentionally unsupported, creation or indexing should report a conflict and leave the system in a state that can be inspected and safely repaired.
Analysis #
On current master (d266005b at the time of investigation), the appview artifacts table has a unique constraint on (repo_did, tag, name). db.AddArtifact uses INSERT OR IGNORE, so a second PDS record with the same tuple can be discarded from appview without an error.
The tags UI reads artifacts from the appview table rather than directly from the PDS or the aggregate artifact query. This makes the ignored record invisible even though it still exists in the owner's PDS.
There is also a deletion concern: the UI deletion route identifies an artifact by repository, tag, and filename. Deleting the visible record can leave the ignored PDS record behind, with no corresponding appview row and no new create event to make it visible later.
Possible directions include storing and addressing artifacts by AT URI or (did, rkey), or otherwise making the uniqueness conflict explicit and ensuring replacement and deletion operate on the intended PDS record.