Package publish leaves a legacy ZIP after a rejected release

[SebTardif]

Summary

Non-npm-pack package publish stores a new legacy ZIP in Convex, then can reject the release (reusable attempt, version already exists, or a throw before insertReleaseInternal). Those paths never delete the new zip id. discardPendingPackagePublicationInternal only deletes blobs already attached to a pending release.

This is a source-level resource leak. I did not run a live production package publish.

Verification / reproduction

1. Read convex/packages.ts publishPackageImpl around the legacy zip ctx.storage.store.
2. Follow the reusable-attempt return, "version already exists" throws, and other returns before insert.
3. Confirm legacyZipStorageId is not deleted on those paths.

Actual

• A rejected non-npm-pack publish can leave an unreferenced ZIP in storage.

Expected

• Store the ZIP after version / reuse checks, or delete legacyZipStorageId on every return or throw before the release row owns clawpackStorageId.
• Successful insert still retains the downloadable ZIP.

Evidence

Source: convex/packages.ts. Proposed patch: PR #3622.

Sibling: #3613 covers multipart packagesV1 stores, not this publishPackageImpl zip.

Security / privacy

Authenticated publisher storage leak. No secret exposure.

Acceptance criteria

• Duplicate / rejected insert does not leave a new unreferenced ZIP.
• Successful insert still stores a downloadable ZIP.
• Discard of a pending release still only deletes blobs that release owns.

This tracker stays open if PR #3622 is closed without landing on main.

[SebTardif]

Proposed patch: #3622

Linked with Ref only. This issue stays open if that PR is closed without landing on main.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 11, 2026, 10:14 AM ET / 14:14 UTC.

Summary
The rejected-publish ZIP leak remains in current main. The contributor already linked an open fix PR, so this security-labeled tracker should remain open without dispatching another repair.

Reproducibility: yes. from source: submit a valid non-npm-pack plugin publication that reaches ZIP storage and then rejects an existing version or fails release insertion. The newly stored ID has no cleanup path; no live publish was executed.

Next step
Review the existing candidate at #3622; the security label, paired PR, and bulk-filing guard preclude a separate automated repair.

Security
Needs attention: Source confirms an authenticated resource leak; no credential exposure or authorization bypass was established.

Review details

Best possible solution:

Allocate the ZIP only when needed, clean up newly allocated but unattached IDs, and preserve existing release artifacts across rejection, retry, and successful publication.

Do we have a high-confidence way to reproduce the issue?

Yes, from source: submit a valid non-npm-pack plugin publication that reaches ZIP storage and then rejects an existing version or fails release insertion. The newly stored ID has no cleanup path; no live publish was executed.

Is this the best way to solve the issue?

Yes, deferred allocation plus ownership-aware cleanup is the narrow repair. Pending-release discard alone cannot solve the pre-insert leak, and successful insertion or reuse must be distinguished before deleting artifacts.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Production storage growth and the frequency of affected rejected publications have not been measured.

Codex review notes: model internal, reasoning medium; reviewed against cbfee7343ddc.

Label changes

Label justifications:

• P2: Authenticated rejected publications can accumulate unreferenced storage, without evidence of an outage or widespread user blockage.
• impact:security: The issue concerns authenticated publisher resource consumption and ownership-safe artifact cleanup.

Evidence reviewed

Security concerns:

• [medium] Rejected publication retains an unattached ZIP — convex/packages.ts:9114
  The action stores a ZIP before rejection or release insertion, and existing cleanup only discovers release-owned storage IDs, allowing rejected publishes to accumulate unreferenced blobs.
  Confidence: 0.98

What I checked:

• Current-main failure path: The checkout matches fetched main. publishPackageImpl stores the legacy ZIP at lines 9114–9130, before staged duplicate checks and either release insertion. Duplicate rejection and insertion failure have no cleanup for this newly allocated ID. (convex/packages.ts:9114, cbfee7343ddc)
• Existing cleanup cannot reach the new ZIP: discardPendingPackagePublicationInternal collects storage IDs only from the existing release's files and clawpackStorageId. Its tests explicitly expect no storage deletion when the release is missing. This does not reclaim an unattached ZIP allocated by the current action. (convex/packages.ts:11350, cbfee7343ddc)
• Reachable entrypoints and narrower reproduction: Authenticated publishRelease and trusted-publisher actions call publishPackageImpl. Staged plugin attempts can reject after ZIP allocation. The report's reusable-attempt return example is narrower on current main: those returns require family claw, which requires npm-pack and skips ZIP creation. (convex/packages.ts:9581, cbfee7343ddc)
• Existing implementation candidate: The issue body and contributor comment explicitly identify fix: delete unpublished package zip on publish failure #3622 as the proposed repair. GitHub REST confirms it remains open and unmerged at head d25c99f. The supplied transcript supports the intended cleanup direction but does not establish a deployed Convex result. (d25c99fa4f40)
• Latest release retains ZIP allocation: The v0.23.3 source also contains the legacy ZIP store before packageInsertArgs; no released fix was established. (convex/packages.ts:8648, 87ca030c30f3)
• History and routing: The GitHub commit patch contains the added legacyZipStorageId allocation and fallback attachment. Raw commit inspection records parent cfcb6bf. Local content-history and blame commands could not complete because historical blobs were unavailable; GitHub REST supplied the relevant patch instead. (convex/packages.ts:9114, 85a3fde60834)

Likely related people:

• unknown: The claimed source-line change could not be verified from bounded local history. (role: source history unknown; confidence: low)
• steipete: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.