🐛 Bug: Copied editor images can never be restored (legacy restore endpoint always 404)
Maintainers usually reply within 1 day
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Stale
- Tech stack
- typescript
- Domain
- backend-api-design, frontend
Research direction
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.
Written by the indexing model from the issue text.
Description
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
- Open a work item and add an image to the description.
- Copy that image in the editor and paste it (the pasted node now has the absolute
/api/assets/v2/...URL assrc). - Make the asset soft-deleted (e.g. delete the original image node; the editor sends
DELETE /api/assets/v2/.../<asset_id>/). - 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)
- Dominant language
- TypeScript
- Stars
- 60.7k
- Forks
- 6k
- Avg merge
- 1d 9h
- Merged PRs (30d)
- 56
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from makeplane/plane
-
[bug]: Email notifications show a broken avatar for users without a profile photoPossibly taken @gurnoorpannu claimed this 3 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
makeplane/plane#10009 · 1 comment ·
Maintainers usually reply within 1 day
-
🐛 Bug: Calendar work items cannot be opened on mobilePossibly taken @pennnnnnnnnn claimed this 5 days ago. Open
Difficulty 1/5 Under an hour Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
[bug]: First day of the week section not translated when Idioma is EspañolPossibly taken @deepcfr claimed this 8 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
makeplane/plane#9967 · 2 comments ·
Maintainers usually reply within 1 day
-
[bug]: First day of the week section not translated when Idioma is EspañolPossibly taken @Indira-kumar claimed this 6 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
[bug]: Analytics "Last 7 / 30 days" windows cover one day too manyPossibly taken @manaskumar3003 claimed this 33 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
makeplane/plane#9830 · 1 comment ·
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
chrisparsons83/flexspotff#215 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
vitest-dev/vitest#11633 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Maintainers usually reply within 1 day