## Problem Two npm delete routes both tombstone and hard-delete inside one transaction, and only the tombstone half reaches `repositories.size_bytes`. This issue owns both arms: - The management package `DELETE`, which hard-deletes at `internal/datastore/npm_package_management_deleter.go:271`. - The protocol whole-package unpublish, which hard-deletes at `internal/datastore/npm_package_unpublish_deleter.go:254`. Both routes make the same call, to `NpmMetadataFileStore.DeleteNpmMetadataFiles`, and one merge request can close both arms through it. `NpmPackageManagementDeleter.cascade` marks the package, its versions, and its files, then calls `removeCacheRows`, which hard-deletes the package's `npm_metadata_files` rows (at most three, one per `kind`) and the `blob_storage_attachments` rows they held, inside the same transaction. The handler arm emits `deleteCounterTargetTombstone`, whose delta set is `Δartifacts` alone, because the footprint counters settle when the lifecycle purger reaps the marked rows. `NpmPackageUnpublishDeleter.cascade` has the same shape. It marks the package with `SoftDeleteNpmPackage` and `CascadeSoftDeleteNpmPackage`, then hard-deletes the same `npm_metadata_files` rows with `DeleteNpmMetadataFiles`. Its handler emits `Δsize = 0` at `internal/format/npm/unpublish_package.go:263`, on the same reasoning about the purger. That reasoning holds for the marked rows and not for the hard-deleted ones. `recomputeNpmFilesSizeStmt` unions `npm_metadata_files` digests into the npm branch of the repository size walk, so a packument's bytes are inside `size_bytes`. The mark is not what removes them; the hard delete is. The purger can never settle them either, because the rows are already gone by the time it reaches the tombstone. `repositories.size_bytes` therefore reads high by the packument blobs' size from the moment either delete commits until a reconciliation pass recomputes that scope. ## Correction to the original scope The original first sentence of this issue claimed that the management package `DELETE` is the one delete target that both tombstones and hard-deletes. That claim is false, and the doc comment on the method this issue cites refutes it: ```go // internal/datastore/npm_package_management_deleter.go:258-261 — removeCacheRows // NpmMetadataFileStore.DeleteNpmMetadataFiles does both halves in this // transaction: its DELETE ... RETURNING reports the attachment each removed row // held, and the npm-family guard frees the ones no npm row still references. It // is the same call the protocol unpublish path makes for the same operation. ``` The scope above corrects that claim. The widening names a second route. It adds no new mechanism and no new remedy. ## Both arms are on `main` Both arms exist on `main` today, and no branch created either one. The branch `prozlach/issue-762-npm-accounting-counters-disagree-adr007` changes the frequency and the visibility of the unpublish arm. It does not change the magnitude, and it does not change the duration. While that branch is unmerged, only a reconciliation recompute puts a packument's bytes on `repositories.size_bytes`. An unpublish therefore leaves residue only when an earlier pass already charged those bytes. Once that branch merges, `emitRebuildCounters` in `internal/format/npm/packument_cache.go` charges the bytes on the write path. Every whole-package unpublish then leaves the residue, and one session is enough to reproduce it. ## Why it is not a delete-emit defect S22 criterion 37's delta table has no row for a target that both tombstones and hard-deletes, so the gap sits in the criterion's model rather than in the emit that implements it. `deleteCounterTarget` cannot express the needed delta set — a tombstone that also frees bytes — so closing it is a widening rather than a one-line change. ## Scale At most three `npm_metadata_files` rows per package, each holding one packument blob. Reconciliation corrects the column on its next pass over the scope, so the drift is bounded in both size and time. Two properties of the pass hold that bound. `RepositoryReconcileStore.WriteBackCounters` takes an absolute `sizeBytes` and overrides the column, so no pass inherits the wrong value. The pass also selects namespaces by staleness rather than from the dirty set, so it reaches the repository whether or not an emit marked it. `reconciliation_interval` is both the tick period and the staleness threshold, and `config.example.yaml:294` defaults it to `1h`. A namespace reconciled at `T` is not a stale candidate before `T + reconciliation_interval`. The next tick that re-selects it can be one interval later again. The wrong value therefore survives about one to two intervals, which is about one to two hours at the default. ## What closing it would take `NpmMetadataFileStore.DeleteNpmMetadataFiles` already runs `DELETE ... RETURNING` and reports each removed row's attachment coordinates. It can report the bytes freed on the repository's last reference through the `repoFreedBlobSizeTx` helper, and the handler arm can carry that into the emit beside `hiddenArtifacts`. That needs a fourth `deleteCounterTarget` value, or a delta set that carries both amounts. Both arms reach that one helper, so one merge request can close both. The unpublish arm needs two more changes of its own. `NpmPackageUnpublishDeleter.cascade` takes no repository id today, and `UnpublishPackage` must carry the freed bytes back to its handler. An amendment to criterion 37's npm-package row belongs with it, so the spec's table and the emit agree on what the arm owes. ## Where this was raised Review of gitlab-org/ops/artifact-registry!1754+s, on the arm in `internal/managementapi/package_delete.go` and on the catalog row in `docs/testing/e2e/npm.md`. Both were corrected in that MR to state the behavior; this issue tracks carrying the bytes. _This is a bot message 🤖 — /smurfit_