## The window A publish resolves its repository, streams its payload, and commits. A destructive repository `DELETE` stamps `soft_deleted_at` and enqueues the purge. When the publish resolved the repository before that stamp and commits after it, the publish answers its own success status and the purge then destroys the rows it wrote. No error reaches the writer. The writer's client is told the artifact exists. It never resolves. ## Which paths this covers Every shape the absence admits, not only the one first noticed: - An npm publish into a hosted repository. `NpmPublishCommitter` locks `npm_packages`, not the `repositories` row, and re-reads no repository state before it writes. - A container manifest push into a hosted repository. `mapImageReResolveError` guards at the image level; no container statement re-checks the `repositories` row. - A **remote** repository is not in scope, and an earlier revision of this issue wrongly said it was. `DispatchHandler.serveRemoteRepository` answers every manifest write and every blob-upload action with `405` through `writeRemoteMethodUnsupported`, and npm takes the same position, so no client write into a remote repository commits and none can reach a window that begins with a commit. `ContainerManifestPersister` writes `container_manifests` and `container_tags` and names no `container_remote_` table. The cache rows a remote repository holds are filled by the read path, and losing one to a purge costs a re-fetch rather than an artifact the caller was told it had. - A Maven upload is **not** affected. `MavenRepositoryStore.ReVerifyRepositoryAlive` re-verifies the parent chain inside the commit, under locks taken at the last moment and held to commit, and the writer gets `404`. The asymmetry with the accepted `delete_all` case matters and is the reason this is filed rather than folded into that precedent. `docs/specs/S17-rest-management-api.md`, `#### delete_all selector`, accepts that "an insert whose transaction spans the acceptance instant stamps `created_at` before it and commits after, so the predicate covers that publish", and says "A caller that needs a publish to survive waits for the collection to drain first". There the repository survives, so the caller can re-read and re-publish. Here the repository is gone, so the success status names something that can never exist and no retry recovers it. ## When it becomes reachable The repository-level tombstone writer is what makes this reachable at all. While the destructive repository `DELETE` is unmerged, no production path stamps `soft_deleted_at` on a repository, so the window cannot open. Once that change merges, the window is open on every npm and container publish that overlaps an accepted destructive delete of the same repository. Merge request !1885 carries that writer, and its F5 review thread is where the acceptance was taken. ## The in-tree mechanism that closes it `MavenRepositoryStore.ReVerifyRepositoryAlive`, reached from `internal/format/maven/upload.go`, is the pattern. It joins `repositories` on `soft_deleted_at IS NULL` with `FOR SHARE`, placed as the last statement before the upsert rather than at the top of the transaction. Commit `03abff448`, in !1540, added that seam together with the Maven package delete that made the race reachable for Maven — the same sequencing this issue describes for npm and container. Extending it to npm and container needs one store method per format and one call site per format, plus a staged-race test per format. npm has no `awaitConflictRendezvous` equivalent today, so that test seam has to be built. ## What makes the locking form expensive `internal/datastore/repository_parent_gate.go` records the cost of holding `FOR SHARE` on a `repositories` row: it blocks every write to that row, including the repository's counter writes, `RepositoryStore.Update`, the hard delete, and the tombstone, and nothing caps that wait. The gate also names a forbidden shape — a caller that takes the lock and later `UPDATE`s the same row in one transaction has to upgrade past every other holder, so two such callers on one parent deadlock where they would previously have queued. Two facts reduce that cost for npm specifically. `MarkRepositoryLastUpdated` runs post-commit on the pool rather than inside the transaction, so npm does not hit the forbidden shape. And npm's commit transaction opens only after the tarball has streamed, so it is already a short sequence of point statements. The interaction to check before choosing the locking form: once S22's chunk drain holds `FOR NO KEY UPDATE` across Redis round trips, a publish waiting on `FOR SHARE` waits on that drain, and neither side is bounded. ## A cheaper partial An unlocked re-read of the repository with `soft_deleted_at IS NULL`, as the last statement before the first write, sees a committed tombstone under READ COMMITTED. It collapses the exposure from the whole upload duration to the few statements between the check and the commit, at the cost of one partition-pruned point `SELECT` per publish, with no new lock and no new conflict edge. It does not close the window. A tombstone committing inside the residual still yields a success status. Its other cost is that it leaves the project with a third distinct per-format answer to one race, and nothing recording why the three differ. ## What was rejected, and why Having the purge spare rows created after the stamp does not work. A spared artifact row makes the finalizer's `DELETE FROM repositories` fail with `23503`, and `docs/specs/S20-a-lifecycle-closed-beta.md`'s `## Error Cases` records that the job then fails and the sweep re-queues it at the bounded cadence. The repository never finishes being removed, so the outcome is a permanent wedge rather than a fix. ## A position that has to be settled with this one Merge request !1942 states, for an npm remote statement, that the repository level is deliberately outside its `EXISTS` because the resolver applies the repository's `soft_deleted_at` gate upstream. That is resolver-gated reasoning on a write path, which is the reasoning this issue records as insufficient once a tombstone can land between the resolve and the commit. Whoever closes this reads !1942's position first. If !1942 merges before the closing change, the closing change revisits that statement; if it is still open, the two are decided together rather than separately. ## Where the acceptance is recorded `api/openapi/v1.yaml`'s `deleteRepository` description and the matching Bruno `docs` block state the window for callers. A `## Error Cases` row in `docs/specs/S20-a-lifecycle-closed-beta.md` records it in the spec, which is otherwise silent on it — the spec's three neighbouring race rows cover the hard-delete race, republish-before-reap, and the parent gate, and none of them is this one.