## Context `docs/adr/007_database_schema.md` defines artifact-level storage accounting in full — sections `#### Artifact-level storage accounting` and `#### Artifact-level storage accounting reconciliation`. S22 excludes this layer and hands it to the format slices; #441 defers the per-format work and asks for one issue per format. This is the Maven issue. Maven is the emptiest of the three: **no artifact-level accounting column exists at all** on the hosted tables, and the one remote column that exists has no writer anywhere in the tree. ## What exists today | Column | ADR-007 | Schema | Writer | | --- | --- | --- | --- | | `maven_versions.size_bytes` | buffered counter, with a `(namespace_id, maven_package_id, size_bytes DESC) WHERE soft_deleted_at IS NULL` index | **does not exist** | — | | `maven_remote_versions.size_bytes` | same | exists (`internal/datastore/migrations/sql/20260731130000_create_maven_remote_versions.sql:23`), and S14 declares it a buffered counter with the size-ordered index | **no store method, no caller** — the column stays `0` and its DESC index orders nothing | | `maven_packages` / `maven_files` counters | none declared | none | — | `maven_files` has no size column by design (`internal/datastore/maven_files.go:54`: "maven_files has no size column, so Size joins from blob_storage_blobs"), so version size is read-derived today. ADR-007 benchmarks that at 58 ms for a top-50-by-size page against 0.06 ms for the indexed column, with the deduplicated derive-at-read variant at ~190 ms. S10 enumerates every buffered column it emits (`repositories.downloads_count`, `artifacts_count`, `size_bytes`, `last_updated_at`, `maven_packages.last_downloaded_at`, `maven_versions.last_downloaded_at`) and omits `maven_versions.size_bytes` entirely, so no spec currently emits it. ## Work 1. Add `maven_versions.size_bytes bigint NOT NULL DEFAULT 0` and the `size_bytes DESC` partial index. Backfill by set-based recompute grouped by version. 1. Maintain it per ADR-007: increment when a `blob_sha256` first attaches to the version, decrement when GC hard-deletes the last attachment of that `sha256` within the version, deduplicated within the version. Soft-delete and restore are no-ops for the counter. 1. Emit from a post-commit site on the upload path. The size is already computed there and dropped: `internal/format/maven/upload.go:541` passes it to `BumpRepoCounters`, whose datastore implementation (`internal/datastore/maven_repositories.go:321`) builds the `UPDATE` and discards it with `_ =`. S22 retires that repository-scoped stub; this issue must not depend on it. 1. Add a writer for `maven_remote_versions.size_bytes` on the cache-fill path, or remove the column and its index. npm's remote twin at least has a store method (`AddNpmRemoteVersionSizeBytes`); Maven has nothing, so decide the two together. 1. Implement ADR-007's artifact-level reconciliation for Maven: distinct `blob_sha256` from `maven_files` joined to `blob_storage_blobs_by_namespace` (created by S22's migration), scoped to one `maven_version_id`. ADR-007 puts per-version cardinality at 4-15 files and the recompute at ~0.6 ms. 1. Add the total `maven_files (namespace_id, maven_version_id)` index that recompute needs. The existing uniques are partial on `soft_deleted_at IS NULL` and split on `maven_version_id` null-ness, so the item-1 backfill and the per-version recompute otherwise scan the namespace's partition through `index_maven_files_on_ns_id_blob_sha256`. npm's same walk earned `index_npm_files_on_ns_id_ver_id`. S17 Phase 8 accepted the namespace-bounded scan for its rare statistics reads. This issue's write-path recompute should not inherit it. 1. Correct S10's buffered-column enumeration to include `maven_versions.size_bytes`. 1. Serialize the version size through S17 once the column exists. ## Out of scope `maven_packages.last_downloaded_at` and `maven_versions.last_downloaded_at` — S18 owns those, and `MavenPackageStore.BumpAccessTimestamps` (`internal/datastore/maven_packages.go:255`) is its dead stub, building two `UPDATE`s and discarding them. Named here only so the boundary is explicit. ## Decisions required - **Buffered or in-transaction** maintenance. ADR-007 says buffered; there is no `bufferedUpdate` equivalent in the Maven slice (npm has one, Maven substitutes inert stubs), so a Maven implementation either builds a mechanism or writes in-transaction with the file rows. Maven has no artifact-level reconciliation implemented to fall back on either way. - **Wire or drop** `maven_remote_versions.size_bytes` (item 4). ## Done when - `maven_versions.size_bytes` is correct after upload, redeploy of an existing version, and file removal, and matches the reconciliation recompute for a seeded version. - `maven_remote_versions.size_bytes` is either maintained on cache fill or removed with its index. - ADR-007's decrement rule has a GC-side emitter, or the dependency on S28 is recorded here. Refines #441. --- > 🤖 **Triage note (automated):** This issue has been reviewed and classified as **`type::feature`**. > > **Reasoning:** This issue requests the implementation of net-new functionality — specifically, adding the `maven_versions.size_bytes` accounting column (which does not yet exist), wiring up a writer for `maven_remote_versions.size_bytes`, implementing ADR-007's artifact-level reconciliation for Maven, and serialising the version size through the API. None of these are regressions or broken behaviour; they are new capabilities being built out for the Maven format slice. > > The following labels have been confirmed on this issue: > - `type::feature` > - `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 leave a comment explaining the correction. Thank you! 🙏