## Bug Description Artifact Registry's npm error envelope carries a usable message, but nests it one level too deep. `error` holds an object, and the npm CLI reads `error` as a string, so the message never reaches the user. `npm-registry-fetch`, which the npm CLI uses for every registry call, builds its user-visible message as `body.error || body.message || JSON.stringify(body)`. An object is truthy, so `body.error` wins the `||` chain, JavaScript renders it as `[object Object]`, and the `message` field nested inside is never consulted. The message AR writes is correct. It is only unreachable. ## Steps to Reproduce Reproducibility: always. Measured 2026-09-14 15:43 UTC. ```shell npm view no-such-package-xyz-20260914 \ --registry "https://$AR_HOST/ar-registry/npm/conformance-npm/" ``` Control, the same command against npmjs.org: ```shell npm view no-such-package-xyz-20260914 --registry "https://registry.npmjs.org/" ``` On the wire, without the CLI: ```shell curl -sS -H "Authorization: Bearer $AR_TOKEN" \ "https://$AR_HOST/ar-registry/npm/conformance-npm/no-such-package-xyz" ``` ## Expected Behavior `error` carries a string, as npmjs.org does, so the npm CLI can render it. Structured fields stay available as siblings. ## Actual Behavior The npm CLI, 10.9.2, side by side: ```text # Artifact Registry npm error 404 Not Found - GET .../no-such-package-xyz-20260914 - [object Object] # npmjs.org npm error 404 Not Found - GET https://registry.npmjs.org/... - Not found ``` The response body: ```json {"error":{"code":"package_not_found","message":"package not found","request_id":"fa828c81-f3a9-4c7a-a089-707a6f17bfd1"}} ``` Same shape on `/-/ping` and `/-/whoami` (`{"error":{"code":"not_found",...}}`), on a scoped name (`@nope%2Fmissing-pkg`), and on a remote repository's write refusals. ## What is already correct, and what is not Worth stating because it makes the fix small: | | Status | | - | ------ | | HTTP status code | Correct (`404` for an unknown package) | | `Content-Type` | Correct (`application/json; charset=utf-8`) | | Body is valid JSON | Correct | | Message text | Correct (`"package not found"`) | | `error` field type | **Object, should be a string** | One field's type is the whole defect. ## Suggested Fix Promote the message and keep the structured fields beside it: ```json { "error": "package not found", "code": "package_not_found", "request_id": "fa828c81-f3a9-4c7a-a089-707a6f17bfd1" } ``` Nothing is lost. `code` and `request_id` stay machine-readable for tooling and support; `error` becomes the string the npm CLI renders. This matches what GitLab's other npm surfaces return (`{"message": "...", "error": "..."}`). No consumer should break: the npm CLI cannot read the nested object today, so anything using the official client is already not depending on it. The change is breaking only for a caller that parses `error.code` directly, which is the reason to make it before GA rather than after. ## Impact Every npm error response from Artifact Registry is unreadable through the official CLI. A user whose `npm publish` is refused sees `[object Object]` and no reason. It also fails seven `registry-conformance` rows, three hosted and four remote: `npm.error.response-shape`, `npm.error.duplicate-publish-body`, `npm.publish.name-validation`, `npm.remote.not-found`, and the three `npm.remote.write-refused-*` rows. ## History Measured three times, unchanged: | Date | Where | Source | | ---- | ----- | ------ | | 2026-09-02 | hosted, staging | Track B hosted conformance report, cause 2 | | 2026-09-04 | remote, staging | Track C remote conformance report, R16 | | 2026-09-14 | hosted, staging | This issue, npm CLI and curl | Recorded as R16 in [registry-conformance#54](https://gitlab.com/gitlab-org/ops/registry-conformance/-/work_items/54). Its four sibling findings from the same 2026-09-02 run were filed here as #1126, #1127, #1129 and #1130; this one was annotated in that index instead of filed, which is why it has no issue on this board until now. ## Suggested DRI Whoever owns the npm error envelope helpers (#124, "npm hosted Step 6: request context, slug resolver, error envelope helpers"), since the shape was introduced there deliberately rather than by accident. ## Labels to Apply - `AR-Blocks::GA`: every npm error path is unreadable through the official client, so a user cannot see why any operation was refused. The fix is one field's type and is breaking only for a caller parsing `error.code` directly, which the npm CLI cannot do today, so before GA is when it is cheapest. - `type::bug`, `bug::functional` - `Category:Artifact Registry`, `artifact-registry::formats`, `backend` - `devops::package`, `group::container registry`, `section::ci` - `format::npm` - `severity::3`, matching #1130: no data loss and no security exposure, but every error path is unreadable through the official client - **`repo-type::*` is deliberately unset.** The envelope is served by both kinds: hosted on 2026-09-02 and again 2026-09-14, remote on 2026-09-04 where `npm.remote.not-found` and the three `write-refused-*` rows fail on it. The scoped label admits one value, so the choice is left to triage rather than made by picking whichever kind has more failing rows. ## Additional Context | | | | - | - | | Environment | staging | | Org slug | `ar-registry` | | Repository | `conformance-npm` | | Format | npm | | Auth method | token exchange, bearer | | Client and version | `npm 10.9.2`, `node v22.15.1`; `curl` for the wire probe | | Observed (UTC) | 2026-09-14 15:43 | | Request ID | `fa828c81-f3a9-4c7a-a089-707a6f17bfd1` | | Workaround | none for the CLI user; a caller reading the raw JSON can reach `error.message` |