fix: delete skill-card blob when attach fails - #3614
Conversation
completeSkillCardJob stored the generated card before attach. A lease mismatch or missing version left an unreferenced Convex blob. Delete the stored id if attach throws. Signed-off-by: Sebastien Tardif <SebTardif@ncf.ca>
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
|
@SebTardif is attempting to deploy a commit to the OpenClaw Foundation Team on Vercel. A member of the Team first needs to authorize it. |
|
Codex review: needs real behavior proof before merge. Reviewed September 11, 2026, 10:08 AM ET / 14:08 UTC (Revision 2). ClawSweeper reviewWhat this changesThe PR deletes newly stored skill-card Markdown when attachment fails and adds tests for failure cleanup and successful retention. Merge readiness⛔ Blocked before merge - 3 items remain The fix remains necessary on current main and v0.23.3. No blocking code findings were identified, but the supplied trace does not satisfy the outstanding real Convex proof requirement. Priority: P2 Review scores
Verification
How this fits togetherClawHub’s skill-card worker generates Markdown and submits it to a Convex action, which stores the file and attaches it to a skill version. The attachment mutation checks the job lease and preserves historical bundle fingerprints. flowchart TD
A[Skill-card worker] --> B[Validate worker token and Markdown]
B --> C[Store new card blob]
C --> D[Attach to skill version]
D -->|Success| E[Retain card and fingerprints]
D -->|Failure| F[Delete new blob]
F --> G[Rethrow attachment error]
Before merge
Agent review detailsSecurityNone. Review metrics
Root-cause clusterRelationship: Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Keep cleanup local to the completion action, deleting only its unattached blob while preserving successful cards and historical fingerprints. Do we have a high-confidence way to reproduce the issue? Yes, source establishes the failure path: store a card, then reject attachment for a stale lease or missing version without deleting the stored ID on current main. No runtime reproduction was executed during this read-only review. Is this the best way to solve the issue? Yes, this is the narrowest repair for the reported exception path and matches existing upload cleanup. A preflight lease check alone would still race with attachment; a broader storage sweeper is unnecessary for this focused fix. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against cbfee7343ddc. LabelsLabel justifications:
EvidenceWhat I checked:
Likely related people:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (1 earlier review cycle)
|
What Problem This Solves
The skill-card worker stores generated
skill-card.mdin Convex storage, then attaches it to the skill version. If attach fails (stale lease or a deleted version), that blob is never deleted. Retries store another orphan. Storage grows on failed worker completions.Evidence
Live
bunrun ofcompleteSkillCardJobagainst this branch.storage.storereturned_storage:proof-card. Attach threwLease mismatch. The handler then calledstorage.deleteon that id.On unfixed main, the same attach failure stops after
storeandattach. There is nostorage.deleteinconvex/skillCards.ts.Real behavior proof
fix/skill-card-store-cleanuponorigin/main0b34234f, livebuncallingcompleteSkillCardJobwith a throwing attach mutation.bun proof-f008.mtsfrom the patched worktree (proof helper not committed)._storage:proof-card. The lease error is rethrown.Summary
Same cleanup class as unpublished skill/package blob deletes. Successful attach still keeps the new blob. Old generated cards stay on success so historical fingerprints remain resolvable.
Tracker
Ref #3674
That issue stays open if this PR is closed without landing on main.