[swissky]

What does this PR do?

Closes #3049

Fixes the first half of #3049: a media delete could report { deleted: true } while the object was never removed from storage, and because the row was already gone nothing could ever find the object again.

• handleMediaDelete(db, id, storage) now owns storage deletion. EmDashRuntime.handleMediaDelete passes its storage adapter, so the MCP media_delete tool removes the file too (its description already promised that; it only deleted the row). The REST route just forwards the result.
• Before the row is deleted, the storage key is registered in _emdash_media_upload_attempts with status cleanup (MediaRepository.trackStorageKeyForCleanup, an upsert on the primary key). The existing cleanup sweep (runSystemCleanup → findUploadAttemptsForCleanup → removeUploadAttempt) already retries rows in that state once the media row is gone, so a failed storage delete is retried on every cron tick instead of being lost. deleteCompletedUploadAttempts skips cleanup rows so a cron tick landing between the upsert and the row delete cannot reap the marker.
• The delete order stays DB row first, then storage — the ordering fix: make media uploads reliable across storage backends #2273 introduced so a delete racing an in-flight upload cannot strand the freshly uploaded object. That existing race test still passes.
• DELETE /_emdash/api/media/:id responds { deleted: true, storageDeleted: boolean } (OpenAPI MediaDeleteResponse). Additive; the admin client only checks the envelope.

Not changed: the public file route still serves any key that exists in storage (second half of the issue). Gating it on a media row adds a query to a logged-out route; with deletes now retried until the object is gone, I'd leave that for a maintainer decision.

Tests (all fail before the fix): route reports storageDeleted: false when storage rejects, the object stays reachable and the next runSystemCleanup removes it; MCP media_delete removes the stored object; a cleanup-marked key survives the sweep while its media row still exists.

Refs #3049 (leaves the file-route question open, see above)

Type of change

• Bug fix
• Feature (requires maintainer-approved Discussion)
• Refactor (no behavior change)
• Translation
• Documentation
• Performance improvement
• Tests
• Chore (dependencies, CI, tooling)

Checklist

• I have read CONTRIBUTING.md
• pnpm typecheck passes
• pnpm lint passes
• pnpm test passes (or targeted tests for my change)
• pnpm format has been run
• I have added/updated tests for my changes (if applicable)
• User-visible strings in the admin UI are wrapped for translation (if applicable). Do not include messages.po changes except in translation PRs — a workflow extracts catalogs on merge to main.
• I have added and reviewed the user-facing changeset (if this PR changes a published package)
• New features link to an approved Discussion: https://github.com/emdash-cms/emdash/discussions/...
• I have included screenshots below if this PR changes the UI

AI-generated code disclosure

• This PR includes AI-generated code — model/tool: Cursor + Claude Fable 5.1

Screenshots / test output

Not applicable (no UI change). i18n and Discussion items are n/a: no admin strings, bug fix.

[changeset-bot]

🦋 Changeset detected

Latest commit: 90c34e2

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 12 packages

Name	Type
emdash	Patch
@emdash-cms/cloudflare	Patch
@emdash-cms/plugin-test	Patch
@emdash-cms/sandbox-workerd	Patch
@emdash-cms/admin	Patch
@emdash-cms/auth	Patch
@emdash-cms/blocks	Patch
create-emdash	Patch
@emdash-cms/gutenberg-to-portable-text	Patch
@emdash-cms/x402	Patch
@emdash-cms/auth-atproto	Patch
@emdash-cms/plugin-embeds	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@emdash-cms/admin

npm i https://pkg.pr.new/emdash-cms/emdash/@emdash-cms/admin@3067

@emdash-cms/auth

npm i https://pkg.pr.new/emdash-cms/emdash/@emdash-cms/auth@3067

@emdash-cms/auth-atproto

npm i https://pkg.pr.new/emdash-cms/emdash/@emdash-cms/auth-atproto@3067

@emdash-cms/blocks

npm i https://pkg.pr.new/emdash-cms/emdash/@emdash-cms/blocks@3067

@emdash-cms/cloudflare

npm i https://pkg.pr.new/emdash-cms/emdash/@emdash-cms/cloudflare@3067

@emdash-cms/contentful-to-portable-text

npm i https://pkg.pr.new/emdash-cms/emdash/@emdash-cms/contentful-to-portable-text@3067

emdash

npm i https://pkg.pr.new/emdash-cms/emdash@3067

create-emdash

npm i https://pkg.pr.new/emdash-cms/emdash/create-emdash@3067

@emdash-cms/gutenberg-to-portable-text

npm i https://pkg.pr.new/emdash-cms/emdash/@emdash-cms/gutenberg-to-portable-text@3067

@emdash-cms/plugin-cli

npm i https://pkg.pr.new/emdash-cms/emdash/@emdash-cms/plugin-cli@3067

@emdash-cms/plugin-test

npm i https://pkg.pr.new/emdash-cms/emdash/@emdash-cms/plugin-test@3067

@emdash-cms/plugin-types

npm i https://pkg.pr.new/emdash-cms/emdash/@emdash-cms/plugin-types@3067

@emdash-cms/registry-client

npm i https://pkg.pr.new/emdash-cms/emdash/@emdash-cms/registry-client@3067

@emdash-cms/registry-lexicons

npm i https://pkg.pr.new/emdash-cms/emdash/@emdash-cms/registry-lexicons@3067

@emdash-cms/registry-loader

npm i https://pkg.pr.new/emdash-cms/emdash/@emdash-cms/registry-loader@3067

@emdash-cms/registry-moderation

npm i https://pkg.pr.new/emdash-cms/emdash/@emdash-cms/registry-moderation@3067

@emdash-cms/registry-verification

npm i https://pkg.pr.new/emdash-cms/emdash/@emdash-cms/registry-verification@3067

@emdash-cms/sandbox-workerd

npm i https://pkg.pr.new/emdash-cms/emdash/@emdash-cms/sandbox-workerd@3067

@emdash-cms/x402

npm i https://pkg.pr.new/emdash-cms/emdash/@emdash-cms/x402@3067

@emdash-cms/plugin-ai-moderation

npm i https://pkg.pr.new/emdash-cms/emdash/@emdash-cms/plugin-ai-moderation@3067

@emdash-cms/plugin-atproto

npm i https://pkg.pr.new/emdash-cms/emdash/@emdash-cms/plugin-atproto@3067

@emdash-cms/plugin-audit-log

npm i https://pkg.pr.new/emdash-cms/emdash/@emdash-cms/plugin-audit-log@3067

@emdash-cms/plugin-color

npm i https://pkg.pr.new/emdash-cms/emdash/@emdash-cms/plugin-color@3067

@emdash-cms/plugin-embeds

npm i https://pkg.pr.new/emdash-cms/emdash/@emdash-cms/plugin-embeds@3067

@emdash-cms/plugin-field-kit

npm i https://pkg.pr.new/emdash-cms/emdash/@emdash-cms/plugin-field-kit@3067

@emdash-cms/plugin-forms

npm i https://pkg.pr.new/emdash-cms/emdash/@emdash-cms/plugin-forms@3067

@emdash-cms/plugin-webhook-notifier

npm i https://pkg.pr.new/emdash-cms/emdash/@emdash-cms/plugin-webhook-notifier@3067

commit: 90c34e2

[emdashbot]

The approach is sound: centralising storage deletion in handleMediaDelete and reusing the existing cleanup sweep lets a failed storage delete retry later while preserving the row-first ordering that protects the upload race. The REST and MCP paths now correctly remove the stored object and surface storageDeleted, and the tests reproduce the failure and cleanup scenarios.

The remaining gap is the plugin-facing delete path. packages/core/src/plugins/context.ts still deletes only the media row and never touches the stored object or the cleanup marker, so plugins calling ctx.media.delete() will leave orphan files behind — exactly the bug this PR is fixing for REST and MCP. That path should share the same cleanup pattern (or delegate to the handler) before merge.

Otherwise the diff is clean: no new logged-out queries, no SQL injection surface, the OpenAPI schema is additive, and the changeset is acceptable as user-facing release notes.

---

Findings

• [needs fixing] packages/core/src/plugins/context.ts:674-684

  The plugin-facing media.delete() still deletes only the database row:

  		async delete(id: string): Promise<boolean> {
  			const deleted = await mediaRepo.delete(id);
  			// ...
  			if (deleted) {
  				invalidateSiteSettingsCache();
  			}
  			return deleted;
  		},

  It never deletes the stored object and never registers the cleanup marker, so a plugin delete leaves an orphan file behind — the same failure mode #3049 fixes for the admin API and MCP. The tests for the site-settings cache even call this out as one of the three media delete paths (packages/core/tests/unit/settings/settings.test.ts).

  It should share the same cleanup pattern as the handler, e.g. by delegating to handleMediaDelete (and adding the import from ../api/handlers/media.js):

  		async delete(id: string): Promise<boolean> {
  			const result = await handleMediaDelete(db, id, storage ?? null);
  			if (result.success && result.data?.deleted) {
  				invalidateSiteSettingsCache();
  				return true;
  			}
  			return false;
  		},
  

  This reuses the row-first delete order, storage failure handling, and retry marker rather than recreating the bug for plugin callers.

[swissky]

Addressed the review: ctx.media.delete() now delegates to handleMediaDelete (same row-first order, storage delete, cleanup marker), with a test that fails without the change. Changeset names the plugin API too. (6934481)

[emdashbot]

Re-review of the media-delete fix.

The plugin-facing gap from the last review is resolved: packages/core/src/plugins/context.ts now delegates ctx.media.delete() to handleMediaDelete, so plugin callers share the same row-first delete order, storage-failure handling, and cleanup-marker retry as the REST and MCP paths. The new tests reproduce the failed-storage-delete and cleanup-marker scenarios, and the OpenAPI response change is additive.

The approach is sound—centralising storage deletion in handleMediaDelete and reusing the existing cleanup sweep means a failed storage delete is retried on every cron tick instead of being lost, while preserving the row-first ordering that protects the upload race.

One real delete path still has the original bug. packages/core/src/media/local-runtime.ts implements the local media provider's delete() and is called by DELETE /_emdash/api/media/providers/:providerId/:itemId. It still deletes the storage object directly, swallows any storage error, deletes the row without registering a cleanup marker, and does so in storage-before-row order. That leaves the same orphan-file failure mode this PR is fixing, and the site-settings cache tests explicitly list local-runtime.delete() as one of the three media-delete paths. It should share the same cleanup pattern, e.g. by delegating to handleMediaDelete.

Otherwise the diff is clean: no new logged-out queries, no SQL-injection surface, the changeset is useful release-facing prose, and comments are acceptable.

---

Findings

• [needs fixing] packages/core/src/media/local-runtime.ts:130

  The local media provider's delete() still handles deletion manually: it calls storage.delete() directly, swallows any error, then deletes the row, with no cleanup marker and no retry path. This is the same failure mode #3049 fixes for the admin API, MCP tool, and plugin API—if the storage delete fails, the row is gone and the object is never found again. The site-settings cache tests also call this out as one of the three media-delete paths.

  It should share the centralized handler so a failed local delete is retried by the cleanup sweep:

  		async delete(id: string) {
  			const result = await handleMediaDelete(resolveDb(), id, storage);
  			if (result.success) {
  				invalidateSiteSettingsCache();
  			}
  		},
  

  This reuses the row-first ordering, storage-failure reporting, and cleanup marker that the other delete paths now use. Be sure to add the import for handleMediaDelete from ../api/handlers/media.js.

[khoinguyenpham04]

Thanks! Just a few things.

[khoinguyenpham04]

could we trim + simplify this comment?

[khoinguyenpham04]

Could we route local-runtime.delete() through handleMediaDelete() and test storage failure? It currently leaves no cleanup marker, so #3049 still affects the local provider.

[khoinguyenpham04]

plese make the cleanup batch advance past repeated failures. right now 100 permanently failing rows can prevent newer deletions from ever being retried.

[github-actions]

Overlapping PRs

This PR modifies files that are also changed by other open PRs:

• feat(plugins): add sandbox media access capabilities #3172 (3 shared files)

This may cause merge conflicts or duplicated work. A maintainer will coordinate.

[swissky]

Rebased onto main and addressed all three findings:

• Trimmed the comment on handleMediaDelete down to a single line.
• The local media provider's delete() now delegates to handleMediaDelete, so it gets the same storage cleanup and retry-queue behavior as the other delete paths. A missing id resolves silently (idempotent); an actual deletion failure rejects.
• Cleanup retry fairness: a failed storage deletion now bumps the attempt's updated_at (deferUploadAttemptCleanup), and findUploadAttemptsForCleanup orders by updated_at, so a persistently failing key moves behind the rest of the batch instead of blocking it. Covered by a new unit test.

Also aligned ctx.media.delete() and the local provider on the same contract: NOT_FOUND is reported as false/silent success, operational failures throw.

[emdashbot]

Re-review of the media-delete fix.

The prior finding is fully resolved: packages/core/src/media/local-runtime.ts now delegates its delete() to the centralized handleMediaDelete helper, so the local provider shares the same row-first delete order, cleanup-marker retry, and site-settings cache invalidation as the REST, MCP, and plugin paths.

I re-checked the complete diff with the AGENTS.md conventions in mind:

• Delete order and orphaned-object safety: handleMediaDelete still deletes the media row before attempting storage deletion. It inserts a cleanup marker into _emdash_media_upload_attempts first, so a failed storage delete survives and is retried by runSystemCleanup; deleteCompletedUploadAttempts now skips cleanup rows, protecting the marker from a sweep that lands between the upsert and the row delete.
• Response / OpenAPI: DELETE /_emdash/api/media/:id now returns { deleted: true, storageDeleted: boolean }, the OpenAPI document uses the new mediaDeleteResponseSchema, and the change is purely additive.
• Plugin and provider paths: ctx.media.delete() and local-runtime.delete() both route through handleMediaDelete; EmDashRuntime.handleMediaDelete passes this.storage so MCP media_delete finally removes the stored object as its description already promised.
• SQL safety: All new queries are built with Kysely; no raw interpolation.
• Logged-out hot path: No new queries on logged-out routes.
• Tests: New regression tests cover failed storage deletion + cleanup-retry for the REST route, the MCP tool, the plugin API, and the local provider, plus a test that cleanup markers survive while the media row still exists.
• Changeset: User-facing prose, names the affected surfaces, and explains the observable behavior.

Everything from the previous review is addressed and I don't see any new blocking issues. LGTM.

[khoinguyenpham04]

Thanks!