Describe the bug
The catalog-transfer workflow deduplicates against the destination catalog using a key of ComponentVersion name + content fingerprint. Neither carries the registry sub-namespace. When the same OCM component at the same version exists under two different sub-namespace prefixes, only the first transfers; the second is classified already_present and never lands at its own specRepo path in the destination registry.
Two mirrors of the same component under different prefixes therefore produce an identical name and an identical fingerprint, differing only in Component.spec.repository.
To Reproduce
Steps to reproduce the behavior:
- Source catalog holds CV X twice: namespace ns-a and ns-b. Same OCM component, same version, same content.
- Item from ns-a transfers. ARC pushes under specRepo = mirror-a.
- Destination discovery creates CV X.
- Item from ns-b: $existing["X"] matches its fingerprint → already_present → skipped.
- Destination registry now has the blobs under mirror-a/ and nothing under mirror-b/.
- Any component resolving relative to mirror-b/'s repository context fails to find it. The destination catalog reports the component as available.
Describe the bug
The catalog-transfer workflow deduplicates against the destination catalog using a key of ComponentVersion name + content fingerprint. Neither carries the registry sub-namespace. When the same OCM component at the same version exists under two different sub-namespace prefixes, only the first transfers; the second is classified already_present and never lands at its own specRepo path in the destination registry.
Two mirrors of the same component under different prefixes therefore produce an identical name and an identical fingerprint, differing only in Component.spec.repository.
To Reproduce
Steps to reproduce the behavior: