Multipart package publish leaves Convex blobs after a failed publish

[SebTardif]

Summary

Authenticated multipart package publish stores the ClawPack tarball and extracted files (or loose uploaded files) before publishPackageImpl validates name, version, account age, and owner. Handler catch maps those failures to HTTP 400 and does not delete the new storage ids.

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

Verification / reproduction

1. Read convex/httpApiV1/packagesV1.ts parseMultipartPackagePublish / publishPackageV1Handler.
2. Follow ClawPack store, extracted-file store, and loose-file storeUploadedPackageFile.
3. Confirm the HTTP 400 catch does not storage.delete those ids.

Actual

• A rejected package publish can leave tarball, extracted files, and artifact blobs unreferenced.

Expected

• Request-local stored ids (files plus artifact) are deleted if parse or publishPackageImpl fails before a release owns them.
• Reused staged tarballs that already belong to another attempt are not deleted by request-local cleanup.
• Successful publishes retain their blobs.

Evidence

Source: convex/httpApiV1/packagesV1.ts. Proposed patch: PR #3613.

Sibling: #3549 is skill multipart only.

Security / privacy

Authenticated publisher storage leak. Not a claimed unauthenticated vuln.

Acceptance criteria

• Failed multipart package publish deletes request-local stored ids.
• Reused staged tarballs are excluded from that cleanup.
• Blobs owned by a committed release are not deleted.
• Successful publish still retains files and artifact.

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

[SebTardif]

Proposed patch: #3613

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

[SebTardif]

PR #3613 is being closed to free a barnacle slot. This issue stays open.

The leak is still real. A later PR can pick it up after the ClawSweeper deletion-safety P1s (reused staged tarballs, post-commit retain) are addressed.

[clawsweeper]

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

Summary
Current main still has the reported leak. The proposed patch was closed unmerged, and the related skill-upload and legacy-ZIP work does not resolve this multipart package path.

Reproducibility: yes. from source: a valid multipart upload stores files before the account-age rejection, and the HTTP catch performs no deletion. No live publish or artifact-producing test was executed.

Root-cause cluster
Relationship: canonical
Canonical: #3673
Summary: This remains the multipart package-upload tracker; the withdrawn patch is not a landed fix, and adjacent leaks have different storage owners.

Members:

• partial_overlap: fix(packages): delete unpublished blobs when package publish fails #3613 - Closed unmerged implementation attempt for this leak, with acknowledged deletion-safety defects.
• adjacent_distinct: fix: delete unpublished skill blobs when publish fails #3549 - Addresses skill multipart uploads rather than package uploads.
• adjacent_distinct: Package publish leaves a legacy ZIP after a rejected release #3677 - Tracks the legacy ZIP allocated inside publication, beyond this HTTP multipart storage boundary.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Next step
Retain this tracker for an ownership-safe replacement; bulk-filer policy and the no-new-fix-pr signal exclude automatic dispatch or proof nudges.

Review details

Best possible solution:

Track request-created blobs through an explicit publication-adoption boundary, settle in-flight stores before cleanup, and prove that rejected uploads are removed while reused and adopted artifacts survive.

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

Yes, from source: a valid multipart upload stores files before the account-age rejection, and the HTTP catch performs no deletion. No live publish or artifact-producing test was executed.

Is this the best way to solve the issue?

An ownership-aware lifecycle repair is the best direction. Early validation alone misses partial storage failures, while unconditional catch cleanup can delete reused or already-adopted artifacts.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Safe cleanup still needs validation across concurrent store failures, reused staged tarballs, and errors after release adoption; HTTP failure alone does not establish that deletion is safe.

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

Label changes

Label justifications:

• P2: Authenticated failed package uploads can leak storage, with no demonstrated urgent outage or user-data loss.
• impact:other: Unreferenced uploaded blobs consume retained storage and operational capacity.

Evidence reviewed

What I checked:

• Current-main identity: HEAD and origin/main both resolve to cbfee73; the working tree is clean. (cbfee7343ddc)
• Stores precede publication validation: Direct tarballs are stored at line 1616, extracted files through storeClawPackFiles, and loose files through Promise.all at lines 1639–1641. The handler invokes publication only afterward and its catch merely converts the error to a response. There is no request-local deletion path. (convex/httpApiV1/packagesV1.ts:2626, cbfee7343ddc)
• Concrete rejection before adoption: publishPackageImpl validates package name/version and calls requireGitHubAccountAge before release insertion. An authenticated user with a too-new GitHub account can therefore reach storage first and then fail publication without any release owning the newly stored files. (convex/packages.ts:8735, cbfee7343ddc)
• Release adoption is separate from HTTP success: Release insertion is followed by awaited inspector-warning writes; staged publication also performs work after release/attempt creation. Existing discard cleanup collects IDs from a pending release, so it does not cover earlier unadopted multipart uploads. A blanket delete-on-error handler would be unsafe. (convex/packages.ts:9438, cbfee7343ddc)
• Staged tarball reuse is intentional: Ticket consumption permits retry with the same storage ID, and uploads.test.ts:201 explicitly tests same-user reuse. Such tarballs cannot be classified as newly allocated request blobs. (convex/uploads.ts:133, cbfee7343ddc)
• Withdrawn patch and distinct related work: GitHub REST confirms fix(packages): delete unpublished blobs when package publish fails #3613 is closed with merged=false. The author’s discussion explicitly preserves this tracker and acknowledges deletion-safety problems. Canonical search found the separate legacy-ZIP issue Package publish leaves a legacy ZIP after a rejected release #3677 and its open candidate fix(packages): reclaim unadopted legacy ZIPs #3622; the supplied fix: delete unpublished skill blobs when publish fails #3549 addresses skill uploads.

Likely related people:

• Peter Steinberger: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• Patrick Erichsen: 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.