## Bug Description `oci.manifest.blob-reference-validation` and `oci.error.manifest-blob-unknown` `PUT` a manifest to a repository name that has had no prior blob upload, and expect `400 MANIFEST_BLOB_UNKNOWN`. Artifact Registry answers `404`, because it registers an image on first blob upload and checks image existence before validating the manifest's blob references. **Which side is wrong is genuinely open**, which is why this is filed separately from [#58](https://gitlab.com/gitlab-org/ops/registry-conformance/-/work_items/58) rather than folded into it: the two share a root cause but not a verdict. ## Steps to Reproduce ```shell regconf run --format oci \ --registry-url "https://<ar-host>" \ --oci-name-prefix "<slug>/container/<repo>" \ --credential "bearer:env:AR_TOKEN" \ --filter 'oci.manifest.blob-reference-validation' --timeout 5m ``` The same `PUT` against a name that already has an image, which is the only difference: ```shell CFG='{"mediaType":"application/vnd.oci.image.config.v1+json","digest":"sha256:0000000000000000000000000000000000000000000000000000000000000000","size":2}' curl -sS -X PUT -H "Authorization: Bearer $TOKEN" \ -H 'Content-Type: application/vnd.oci.image.manifest.v1+json' \ --data "{\"schemaVersion\":2,\"mediaType\":\"application/vnd.oci.image.manifest.v1+json\",\"config\":$CFG,\"layers\":[]}" \ -w '\nhttp=%{http_code}\n' \ "https://<ar-host>/v2/<slug>/container/<repo>/<existing-image>/manifests/probe" ``` Reproducibility: always Reproduced independently: yes, on Artifact Registry staging 2026-09-02 ## Expected Behavior A manifest `PUT` whose config or layer digests are not present is rejected `400 MANIFEST_BLOB_UNKNOWN`, naming the missing digest. That is what the rows assert and what the OCI distribution spec pins for the condition. What the spec does not pin is the precedence between "this name is unknown" and "this manifest references an unknown blob" when both hold. That is the open question here. ## Actual Behavior Through the suite: ```text FAIL oci.manifest.blob-reference-validation oci: PUT https://<ar-host>/v2/<slug>/container/conformance-oci/conformance/<runID>/oci-manifest-blob-reference-validation/manifests/sha256:d9428960…: status 404 FAIL oci.error.manifest-blob-unknown oci: PUT …/oci-error-manifest-blob-unknown/manifests/sha256:2c85481f…: status 404 ``` Against a name that already has an image, the registry returns exactly what the rows want: ```json {"errors":[{"code":"MANIFEST_BLOB_UNKNOWN", "message":"manifest references an unknown blob or manifest", "detail":{"digest":"sha256:0000000000000000000000000000000000000000000000000000000000000000"}}]} ``` with `http=400`. So the registry's manifest validation, its error code, and its `detail.digest` are all correct. Only the ordering of the two checks differs from what the rows assume. ## Suggested Fix **This section is a hypothesis, not a finding.** This one needs a decision before it needs a patch. The two readings: 1. **The rows should establish the image first**, as [#58](https://gitlab.com/gitlab-org/ops/registry-conformance/-/work_items/58) proposes for the not-found rows. Then the manifest validation is reached and the assertion holds unchanged. Cheapest, and consistent with how a real client arrives at a manifest `PUT`: it has already uploaded blobs. 2. **The registry should validate blob references before image existence.** Defensible on the grounds that a manifest `PUT` is itself what creates an image, so requiring the image to pre-exist makes the endpoint unreachable for a first push that goes manifest-first. Reading 2 is worth putting to the Artifact Registry team rather than deciding here, because a registry that creates the image on manifest `PUT` and one that requires a prior blob upload are both defensible and the spec does not choose. Docker's own push order uploads blobs first, which is why Track A's `docker push` succeeded against this registry and these rows did not. If reading 2 wins, this becomes an Artifact Registry issue and should be moved; if reading 1 wins, the fix is in this repository next to #58's. ## Suggested DRI Conformance tooling, DRI @radbatnag, reviewers @mkhalifa3 and @sylviashen, for reading 1. If the resolution is reading 2, S12 OCI (hosted), DRI @hswimelar, owns it instead. The `closed-beta.md` workstream table notes the conformance DRI needs re-confirming. Unassigned, per triage policy: the assignment depends on which reading wins. ## Labels to Apply - `type::bug` - `severity::3` — two rows, and the registry's manifest validation is demonstrably correct once reached, so the cost is two false failures plus an unresolved spec question. Not `severity::2`: no capability is unusable. - `Category:Artifact Registry` - `artifact-registry::devex` — closest stream label while the fix is expected in this repository. Re-label to `artifact-registry::formats` if the resolution moves it to the registry. - `backend` - `format::oci`, `repo-type::hosted` - `bug::functional` - No `AR-Blocks::*`: does not block an Artifact Registry release. ## Additional Context | | | |---|---| | Environment | Artifact Registry staging | | Org slug | `ar-registry` | | Repository | `conformance-oci`, hosted, format `docker` | | Format | OCI | | Auth method | token exchange, bearer | | Client and version | `registry-conformance` at `7ca1a6be` plus the `--oci-name-prefix` change | | First observed (UTC) | 2026-09-02 22:05, run ID `3ffb816fedc05659` | | Correlation ID | _Not captured; the suite logs `request_method: PUT` without the response's request id._ | | Workaround | read the two rows as expected failures until the precedence question is settled |