Non-blocking follow-ups from @mkhalifa3's review of !250031 (S02 Step 2, provisioning) and !250045 (S02 Step 3, disable/enable). Both MRs are approved; these were explicitly left as follow-up material so they do not gate merge. Grouped into three categories. None is blocking. ## Category A: small code touch-ups in the client and its specs These are the one-liners mkhalifa3 suggested that were not folded into the approved MRs. - [ ] **Pin `RETRY_OPTIONS` shape so `retry_if` cannot silently bypass the `methods` gate.** In faraday-retry 2.4.0, `retry_request?` is `methods.include?(...) || retry_if.call(...)`, so a future `retry_if` would OR-bypass the idempotent-method allowlist that protects the state-changing POSTs. Add a spec next to the retry examples asserting the constant's keys: ```ruby expect(described_class::RETRY_OPTIONS.keys).to match_array(%i[max interval exceptions methods]) ``` Thread: !250031#note (disc 06928a6da8). - [ ] **Correct the 409-passthrough spec claim.** The `surfaces an anchor mismatch identically to a taken slug` example fabricates the AR envelope in the test, so it pins client passthrough of the envelope `code`, not an AR-side split of `conflict` into two codes. My in-thread reply overstated what the test proves. Adjust the spec comment (and concede in-thread) to say exactly "client passthrough". The AR-side split stays tracked by ops/artifact-registry#383. Thread: !250031#note (disc 970adcabda). - [ ] **Add `:aggregate_failures` to the one multi-expectation example that is missing it.** `it 'raises ApiError carrying the status'` in the condition specs holds three expectations with no tag, while every sibling carries it (`testing-rspec.md`: use the tag when there is more than one expectation). Thread: !250045#note (disc acbfef17ec). ## Category B: observability, action-level attribution - [ ] **Distinguish disable from enable in error reports.** Terminal reports for the condition POSTs carry `url` (base), `method: :post`, `uuid`, and `status`, but never the action, so a `disable_namespace` 400 and an `enable_namespace` 400 for the same uuid are identical on every key except `request_id`/`correlation_id`. The enable direction is the unsafe one when a response is lost, so telling them apart in telemetry has value. Fix requires adding an allowlisted context key (for example `action`) to `ErrorReporter::ALLOWED_CONTEXT_KEYS` and threading `action:` from `namespace_condition`, with a paired amendment to the sentinel spec that pins the allowlist. It touches the allowlist S02 Step 1 deliberately locked down, so it is its own change. This is the same gap as the deferred `ar_endpoint:` observability item: a failed AR call's context has no operation dimension (`url` is the base URL, the class is always `UnavailableError`, `method` is only the HTTP verb, so a `POST` could be create/provision/disable/enable). The general fix is a stable low-cardinality operation label threaded from each public method, which subsumes the `action` key here. Consider doing both together. Thread: !250045#note (disc 7859567c30). ## Category C: consumer-facing contract notes for S10 No monolith code change. These document behaviour the S10 provisioning caller must handle, and belong in the S10 spec/plan in `gitlab-org/ops/artifact-registry`, not here. - [ ] **4xx `ApiError` outcomes produce no error-tracking record.** The `raise_error` else branch raises `ApiError` carrying AR's `message` after Bearer/JWT-only redaction, and does not log. So the S10 caller must log the `ApiError` itself; `status`, `code`, and `request_id` are available. Also add a one-line comment at that boundary in the client naming it (caller-facing messages deliberately bypass the report surfaces; slugs are not credential-shaped). Thread: !250031#note (disc e5dd76ffb7). - [ ] **`UnavailableError` may carry a 2xx status for unexpected-success outcomes.** The id-guard raises `raise_unexpected_success`, which passes `status: response.status` into `raise_terminal`. If AR applies a disable/enable and answers with a body the client cannot shape (a 204, a differently-shaped 201, a truncated body, or contract drift), the caller sees an availability error carrying a success status, after the state change may already be applied. The S10 caller should branch retry/breaker logic on `error.status`, not the error class alone. Optionally split availability failures from contract failures with a distinct subclass in `raise_unexpected_success`. Thread: !250045#note (disc caae3eaa4f). ## Open question captured (not a task) - The id guard checks `attributes['id'].blank?`, not UUID shape, so `id: 0` / `id: '42'` / a nested object would pass. `namespace()` has the identical guard, so this is a deliberate shared choice; non-blank is the intent. If we ever decide to tighten, enforce `attributes['id'].is_a?(String) && UUID_REGEX.match?(attributes['id'])` in all three places symmetrically. Recorded here so the decision is not silently revisited. Thread: !250031#note (disc a8381807f4).