Repository navigation
Plugin delete reports success but the record persists #429
Description
Deleting a plugin from the plugin edit page (the ... menu, Delete, confirm) shows the "Plugin deleted." toast, but the record survives: reloading the plugin page and the edit page still resolves it, and a later submission of the same name gets a -1 suffixed slug because the "deleted" row still owns it.
Looking at apps/cursor/src/actions/delete-plugin.ts, the delete goes through the user-scoped Supabase client with .delete().eq("id", id).eq("owner_id", userId). If the RLS delete policy does not match, that affects zero rows without raising an error, so the action returns success without deleting. A zero-row delete reporting success would explain what we see.
Happened twice to us on cursor.directory (account auscaster):
- Deleted the manually created plugin at /plugins/ausca. Toast said deleted; the record is still live.
- Resubmitted the same plugin via the Auto (GitHub) flow from https://github.com/auscahq/ausca. Because the old row survived, the new one landed at /plugins/ausca-1 with all six components correctly auto-scanned (one MCP server, five skills).
The cleanup we would like, in preference order:
- Preferred: delete only the stale /plugins/ausca record (one hand-made component, superseded) and move the complete /plugins/ausca-1 record onto the freed ausca slug. That record is fully scanned and correct; a slug rename preserves it as-is with no resubmission.
- Alternatively, hard-delete both rows and we resubmit once cleanly.
Happy to provide any account confirmation you need. Thanks for the directory, the Auto scan flow detected all six of our components perfectly.
Activity
deanrie commentedon Oct 5, 2026
Hey @auscaster, thanks for the precise write-up, and the read of
delete-plugin.tsmatches what we see on our side: a zero-row delete under the user-scoped client reports success without deleting, so the stale row keeps the slug and the resubmission lands on-1. There's no self-serve way through that today; it needs a backend cleanup by the directory team.I've attached this to the internal ticket with your preferred outcome spelled out: drop the stale
/plugins/auscarow and move the fully scanned/plugins/ausca-1onto the freedauscaslug, with hard-deleting both and a clean resubmit as the fallback. I'll update here when it's done.deanrie commentedon Oct 8, 2026
Update: #443 changes the delete action so a delete that removes no row fails with an error instead of showing "Plugin deleted." It won't clear the listing from this report by itself, that still needs the backend cleanup tracked internally, but it stops the UI from claiming success when nothing happened, which is the part this repo can fix.