## Context Merge request https://gitlab.com/gitlab-org/ops/artifact-registry/-/merge_requests/2324 bounds the lifecycle purger's counter emit behind `counterEmitMaxInFlight` in `internal/lifecycle/emit_dispatch.go`: a process-wide cap of 64, acquired without blocking, that sheds past the cap. Work item https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/871 accepted that shape, in note 3767932126, as "shape C". That note sized the cap against **one** purge attempt and reasoned about **two** states: a healthy emit that returns in milliseconds and never fills the cap, and a stalled Redis that fills all 64 slots in 0.64 to 3.2 seconds. On those two states the cap is a discriminator rather than a throttle, which is what made shape C acceptable. ## The gap The accepted reasoning never multiplied by the concurrent attempt count. `jobsriver`'s `defaultMaxWorkers` is 25 per pod and is shared with every other job kind, and nothing holds the purge kind to fewer, so up to 25 purge attempts can dispatch at the same time. In-flight is the dispatch rate times how long a worker holds its slot. The purger dispatches once per committed chunk, so the per-scope emit latency that fills all 64 slots is `64 × chunk duration ÷ concurrent purge attempts`, and half that for a chunk owing both scopes. Across the 20 ms to 100 ms healthy chunk cadence `internal/lifecycle/chunk.go` illustrates, and with all 25 workers on a purge attempt, the shed starts between 26 ms and 256 ms. That cadence is unmeasured: no signal in the tree reports a chunk's duration, and `DefaultPurgeChunkSize` in `internal/lifecycle/purge.go` is where that absence is recorded. That is a third state the two-state reasoning does not name: Redis answering slowly but still answering. In that state the purger sheds committed chunks' deltas, where the inline shape it replaces lost nothing and only slowed the purge. The loss is not permanent, because the storage-accounting reconciliation pass recomputes the scope from the committed rows, but the counters read high until that pass reaches the namespace. This work item is about the value and the operational response rather than about the documentation. While merge request 2324 is open, the corrected reading lives on its branch; once it merges, `docs/dev/observability.md` and `docs/dev/storage-accounting.md` both carry the arithmetic above. ## What to do Before and during the rollout of the purger's detached emit, watch: - `gitlab_artifact_registry_lifecycle_purge_counter_emit_drops_total{purge_emit_drop_reason="shed"}`. A shed writes no log line, so this series is the whole of the record it leaves. - `gitlab_artifact_registry_lifecycle_purge_duration_seconds` beside it, which with the chunk count gives the cadence the arithmetic above needs. Three inputs that arithmetic needs have no signal of their own today: how long a chunk takes, how long a worker holds its slot, and how many purge attempts run at once. The chunk duration is the one the shed-onset range above is built on, and `DefaultPurgeChunkSize` in `internal/lifecycle/purge.go` is where its absence is recorded. Whether either is worth a series is part of what to decide here. Decide from what those show: - Whether 64 is the right value for GitLab.com at this site, given that one cap is shared across every namespace being purged. - Whether the acquire should gain a bounded blocking budget before it sheds, so that ordinary slowness produces backpressure rather than loss. `internal/accounting/doc.go` leaves that choice to the call site. The shed-do-not-queue rule at `internal/format/npm/packument_cache.md:254` is what argued against it for this site, because the cap bounds a spawn and parking would hold one of River's 25 shared workers. - Whether a per-namespace sub-quota is worth having. One attempt can hold every slot and shed another namespace's deltas, and Maven's `bufferedUpdateMaxPerLabel` is the only per-label sub-quota in the set today (https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/559). - Whether an alert on the shed rate is worth having, and at what threshold, given that the onset moves with the attempt concurrency. ## Neighbouring work items, and why none of them owns this - https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/756 — the same watch-during-rollout shape, on npm remote reads' fill-slot hold time and detached cache bumps. A different cap on a different path. - https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/632 — a shed write on an unowned buffered-counter column drifts permanently for want of reconciliation. The purger's two columns are owned, and the reconciliation pass recomputes them. - https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/559 — unifies the eleven per-consumer caps by the resource they draw on. It is about how each cap is sized, not about the latency at which one starts shedding. - https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/920 — closed on 2026-09-01. It settled which goroutines may emit and left detach, bound, spawn and shed to each call site. ## Source Raised in review of merge request 2324 by @sylviashen, note 3786951921, as an operational question rather than a change that merge request should carry. The remedy proposed there, a bounded blocking acquire, was declined for that merge request on the shed-do-not-queue rule. The latency state it identified is what this work item carries. Related to https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/871