mirror of
https://tangled.org/evan.jarrett.net/at-container-registry
synced 2026-09-02 00:06:58 +00:00
2e55352taught the scan broadcaster that a successor label is only interesting when it points at us; the GC copy of the same check was left accepting any non-empty successor. Confirmed still divergent at the head of this stack: gc.go was a bare `if captain.Successor != ""` while scan_broadcaster.go:1473 compares against sb.holdDID. A hold that retired into some third hold is that hold's predecessor, not ours, and its manifests are not a reason to keep blobs referenced here. GC therefore now makes the same comparison the broadcaster does, against gc.pds.DID(). This is the one change in the batch that makes GC delete more rather than less, so it is deliberately its own commit and carries a floor. If this hold cannot say who it is, ourHoldDID() returns "" and the old permissive answer stands: we cannot conclude a successor is not us, and over-protecting merely leaks blobs while guessing the other way destroys them. That branch has its own test, because an empty DID silently turning every predecessor into a stranger is exactly how this reconciliation would become the next blob-loss bug. The inconclusive-on-failure semantics95d4f7cadded are untouched: only the answers from a hold that actually replied are affected. Verified by mutation: forcing the comparison back to the permissive form fails exactly one case, the successor naming a third hold, and leaves the unknown-own-DID fallback passing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>