Multipart skill publish leaves Convex blobs after a failed publish

[SebTardif]

Summary

Authenticated multipart skill publish (POST /api/v1/skills) stores each uploaded file in Convex, then can reject the request during parse or later validation. Those stored ids are not deleted. Failed publishes leave unreferenced blobs.

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

Verification / reproduction

1. Read convex/httpApiV1/shared.ts parseMultipartPublish (store, then parsePublishBody).
2. Follow the handler path that returns 400 after a successful store.
3. Confirm there is no storage.delete of those new ids on that failure path.
4. Compare with the sibling scan upload path in the same file, which already deletes on failure.

Actual

• Failed multipart skill publish can leave stored files that no skill version owns.

Expected

• Stored ids from the request are deleted unless a published (or otherwise persisted) version owns them.
• Successful publishes still retain their blobs.

Evidence

Source: convex/httpApiV1/shared.ts. Proposed patch: PR #3549.

ClawSweeper also asked that blobs already committed to a version stay retained. That commit-then-keep rule belongs in the same fix.

Security / privacy

Storage leak for an authenticated publisher. Not a claimed remote unauthenticated vuln. No payload.

Acceptance criteria

• Request-local stored ids are deleted when parse or publish fails before a version owns them.
• Blobs already committed to a version are not deleted by request-local cleanup.
• Successful publish still attaches and retains the files.

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

[SebTardif]

Proposed patch: #3549

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:12 AM ET / 14:12 UTC.

Summary
The leak remains in current main. The author's linked fix PR is still open, so this issue should remain its tracker without dispatching another repair.

Reproducibility: yes. from source: submit an authenticated multipart request containing a file and valid JSON that omits slug, or omit license acceptance; storage succeeds before rejection without cleanup. No live Convex reproduction was executed.

Next step
Review the existing repair at #3549; its pairing and the bulk-filing guard exclude another automated fix dispatch.

Review details

Best possible solution:

Track request-owned uploads through validation and persistence, deleting only unowned blobs and preserving published or pending-version files even when later follow-ups fail.

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

Yes, from source: submit an authenticated multipart request containing a file and valid JSON that omits slug, or omit license acceptance; storage succeeds before rejection without cleanup. No live Convex reproduction was executed.

Is this the best way to solve the issue?

Yes, request-local cleanup with an explicit persistence boundary is the narrow repair; validating earlier alone cannot cover later store or publish failures, and deleting on every HTTP error could damage committed versions.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The retained storage volume and operational cost have not been measured against a real Convex deployment.

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

Label changes

Label justifications:

• P2: Authenticated failed publishing leaks storage resources without demonstrated outage or blocked user recovery.
• impact:other: Unreferenced uploaded blobs consume persistent storage; the report does not establish data loss or an authorization bypass.

Evidence reviewed

What I checked:

• Current-main leak: The checkout matches fetched main. parseMultipartPublish stores files at line 425, then validates the completed payload at line 450 without cleanup. A valid JSON payload missing slug can therefore fail after storage succeeds. (convex/httpApiV1/shared.ts:425, cbfee7343ddc)
• Handler failure and existing regression fixture: The multipart handler rejects omitted license acceptance after parsing and maps exceptions to HTTP 400 without deleting uploaded files. The existing test at convex/httpApiV1.handlers.test.ts:8511 exercises that rejection but asserts no storage cleanup. (convex/httpApiV1/skillsV1.ts:2616, cbfee7343ddc)
• Existing cleanup does not cover multipart publication: The sibling scan parser prevalidates files and deletes stored IDs on failure. Direct-upload cleanup instead requires a skillPublishUploadTickets record; the multipart parser creates no such ticket. (convex/skillPublishUploads.ts:160, cbfee7343ddc)
• Commit-aware retention boundary: Publication persists a version before awaiting follow-up scheduling; staged publication also persists a pending version before creating its attempt. An HTTP failure alone cannot establish that uploaded files are safe to delete. (convex/lib/skillPublish.ts:581, cbfee7343ddc)
• Existing implementation candidate: The issue and author comment explicitly link fix: delete unpublished skill blobs when publish fails #3549. GitHub REST confirms it remains open and unmerged at the recorded head. Its supplied evidence uses mocked storage, not a live Convex storage run. (d4bcf53fd927)
• History and release inspection: Recent file history identifies Patrick Erichsen's publishing work and Peter Steinberger's staged-artifact recovery work as routing signals. GitHub confirms the latest release is v0.23.3; no fixing release was established. Detailed blame and older blob inspection could not complete because required historical objects were unavailable, so introduction attribution remains unknown. (convex/httpApiV1/shared.ts, cbfee7343ddc)

Likely related people:

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