🐛 Bug: Copied editor images can never be restored (legacy restore endpoint always 404)

オープン
  • 何か問題がありますか？
#9,993 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@ygpark2 がすでに取り組んでいます。

2026年10月13日 から。

  • #9994 @ygpark2 による — オープン

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
停滞
技術スタック
typescript
領域
backend-api-design, frontend

調査の方向性

Read the restore handlers in apps/web/hooks/editor/use-editor-config.ts and apps/space/helpers/editor.helper.ts, then trace the legacy and v2 restore calls described in the issue. Confirm how each handler chooses an endpoint for an absolute v2 asset URL. Done means restoring that image uses the working v2 endpoint; issue #9994 already has an open linked pull request.

索引モデルが issue の本文から書いたものです。

説明

Is there an existing issue for this?
  • I have searched the existing issues
Current behavior

Images whose node src is an absolute v2 asset URL can never be restored once their asset gets soft-deleted, so they stay broken ("Error loading image") forever.

Such nodes are common: copying an image from a rendered editor and pasting it produces

<img data-id="…" src="https://plane.example.com/api/assets/v2/workspaces/<slug>/projects/<project_id>/<asset_id>/" …>

i.e. the resolved URL instead of the asset id.

The editor file handler decides the restore endpoint only by src.startsWith("http")
(apps/web/hooks/editor/use-editor-config.ts, same in apps/space/helpers/editor.helper.ts):

restore: async (src: string) => {
  if (src?.startsWith("http")) {
    await fileService.restoreOldEditorAsset(workspaceId, src);   // POST /api/workspaces/file-assets/<workspace_id>/<last path segment>/restore/
  } else {
    await fileService.restoreNewAsset(workspaceSlug, src);       // POST /api/assets/v2/workspaces/<slug>/restore/<asset_id>/
  }
},

For an absolute v2 URL the last path segment is the asset id, but the legacy endpoint (FileAssetViewSet.restore) looks the asset up by its storage key (FileAsset.objects.get(asset="<workspace_id>/<asset_id>")), which never matches. The request always fails with 404 (FileAsset matching query does not exist) and the asset stays is_deleted=True / deleted_at set, so GET /api/assets/v2/.../<asset_id>/ keeps returning 404.

On our self-hosted instance every call to the legacy restore endpoint over ~2.5 months failed (51/51 → 404), while the v2 restore endpoint succeeded (62/62 → 204). The soft delete itself is triggered by the editor while the image is still in the document (e.g. cut/paste or undo while composing a work item), so users end up with broken images right after creating the work item.

Steps to reproduce
  1. Open a work item and add an image to the description.
  2. Copy that image in the editor and paste it (the pasted node now has the absolute /api/assets/v2/... URL as src).
  3. Make the asset soft-deleted (e.g. delete the original image node; the editor sends DELETE /api/assets/v2/.../<asset_id>/).
  4. Reload the work item: the remaining image fails to load, the editor calls POST /api/workspaces/file-assets/<workspace_id>/<asset_id>/restore/ → 404, and the image shows "Error loading image" permanently.

Expected: the restore goes to POST /api/assets/v2/workspaces/<slug>/restore/<asset_id>/ (which works) and the image is shown again.

Environment

Production

Browser

Google Chrome

Variant

Self-hosted (Community)

Version

v1.4.2 (logic unchanged on preview as of bab49bb)

主要言語
TypeScript
スター
61.9k
フォーク
6.3k
平均マージ
1日 20時間
マージ済み PR（30日）
73

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

makeplane/plane のほかの issue

makeplane/plane の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。