## Summary The hosted reap arms report no size delta today. Each one deletes rows whose bytes the repository counter still holds, so `repositories.size_bytes` reads high until a reconciliation pass corrects it. The correct delta is repository-scoped. **Only the reap can compute it.** An emit site that runs after the chunk transaction commits cannot, because the deleted rows and their digests no longer exist at that point. This issue records the derivation so that the person who adds the emit site does not have to find it again, and does not conclude that the computation is impossible. ## Why the version-scoped number is wrong `maven_versions.size_bytes` sums the blob sizes of the version's own distinct digests. `repositories.size_bytes` sums the repository's distinct digests, across every package and version. One digest attached under two versions of one repository is taken up **once** by the repository counter. Reaping the first version decrements it. Reaping the second decrements it again. The error has one direction and accumulates: an increment fires once per repository, a decrement once per version, so no later reap cancels an earlier over-decrement. The worst case is the whole emitted figure, when every digest in the reaped version survives elsewhere in the repository. A promote-by-copy pipeline produces exactly that shape. The counter is user-visible. `internal/managementapi/resource.go` and `list.go` serialize `size_bytes`, and `list.go` maps a `size_bytes` sort parameter. No `CHECK (... >= 0)` constraint guards the column, and a persistent negative value is an investigate signal rather than a crash. ## The trap that makes this worth writing down **The acceptance test for the emit step passes under either scope.** One version pushed into an empty repository has one digest. The version-scoped sum and the repository-scoped sum are equal for that fixture. A test that pushes one artifact, tombstones it, purges it, and asserts the counter returns to zero is green whichever number the reap emitted. The divergence needs a second attachment of the same digest, under a different version of the same repository. A fixture without that shape cannot see the defect. ## The repository is reachable from the deleted rows The obstacle is not that the reap cannot find the repository. `TombstoneRow` does not carry it, but the deleted rows do, through their foreign keys. Maven: ```plaintext maven_files.maven_package_id -> maven_packages.maven_repository_id -> maven_repositories.repository_id ``` `maven_packages.maven_repository_id` is at `internal/datastore/migrations/structure.sql:13691`, and `maven_repositories.repository_id` at `:18831`. npm has the same shape, confirmed independently: ```plaintext npm_files -> npm_versions -> npm_packages -> npm_repositories -> repositories ``` The walk starts on rows the reap holds while they still exist. ## What the computation is For each digest the file page deleted, ask whether any surviving `maven_files` row of the **same repository** still carries it. Sum the blob sizes of the digests with no survivor. That sum is the delta. The reap already returns the deleted rows' digests, because the bounded page `DELETE` uses `RETURNING` to make the page countable and its attachments reachable. ## Current state Both hosted arms leave the size delta at zero and state the gap in a comment on the exported reap symbol. The remote arms leave it zero as well. Nothing emits any of these values yet, because no chunk driver is in the tree. When the emit step opens, it either adopts this computation inside the reap, or it accepts a counter that reads high until reconciliation and says so. The one option that is not available is deriving the repository-scoped delta after the chunk commits. ## Scope - Applies to the Maven and npm hosted reap arms, and to `ContainerRemoteManifestReaper`. That reaper is reached as an artifact purge, so its zero is a gap on the same terms as the hosted arms'. `ContainerRemoteImageReaper` is reached as a repository purge, whose delta is the repository row's own deletion, so its zero is correct and is out of scope. - Changes `ReapTotals.SizeBytes` for every implementation, so it is a plan-level decision rather than one arm's choice. - The reconciliation pass that would correct a wrong value is a separate mechanism. It corrects a drifted counter; it does not make a wrong delta right. Related to https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/611 _This is a bot message 🤖 — /smurfit_ --- > 🤖 **Triage note** — This issue was automatically classified as **`type::bug`**. > > **Reasoning:** The issue describes incorrect behaviour in the system: the reap arms emit a zero size delta instead of the correct repository-scoped delta, causing `repositories.size_bytes` to read artificially high after purge operations. This is a functional defect with a user-visible impact (the size counter exposed through the management API is wrong), which squarely fits the `type::bug` definition. > > The following labels have been confirmed on this issue: > - `type::bug` > - `Category:Artifact Registry` > - `devops::package` > - `group::package registry` > > If this classification doesn't look right to you, please feel free to update the labels and let the team know — your context is always more accurate than automated triage!