Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

🐛 Bug: Concurrent edits silently overwrite work item descriptions (lost images/text)

Open
  • Is something wrong?
#9,995 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@NadaaFarook is already working on this.

Since Oct 13, 2026.

  • #9999 by @NadaaFarook — open

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
django, python, react, typescript
Domain
api, backend, frontend

Research direction

Start with IssueViewSet.partial_update in apps/api/plane/app/views/issue/base.py and the document type definition in apps/live/src/types/index.ts; trace how the editor autosaves descriptions and how page collaboration is handled. Compare the concurrency and collaboration options in the issue, then define how stale edits are detected or merged. Done means concurrent edits no longer silently discard another user's description content; verify with the two browser steps described above.

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

When two people have the same work item open, the one who saves last silently overwrites what the other saved in the meantime, including newly added images. Nobody gets a warning and nothing is merged. The lost content only shows up in the description version history.

Why it happens

  • The web editor autosaves the whole description with PATCH /api/workspaces/<slug>/projects/<project_id>/issues/<id>/, sending { "description_html": ... }.
  • IssueViewSet.partial_update (apps/api/plane/app/views/issue/base.py) stores the received description_html as is. There is no version, updated_at or ETag check, so it is last-write-wins.
  • Work item descriptions are not collaborative. The live server only handles project_page documents (apps/live/src/types/index.ts: TDocumentTypes = "project_page"), so an open editor never receives other users' changes. Its next autosave writes its outdated copy back.

What we observed in production (self-hosted v1.4.2)

API logs with user ids, together with issue_description_versions, show this timeline on one work item (times in seconds, users A and B):

t event
0 B opens the work item (description has 4 images)
+9 s A pastes a new image 6ef7e0ca… (asset upload + PATCH asset 204)
+11 s, +14 s A's description autosaves (PATCH 204), image included
+69 s B saves without having reloaded → 6ef7e0ca… is gone
  • The asset of the lost image was never deleted (deleted_at is NULL, no DELETE request). It was simply overwritten.
  • Earlier the same day, B's stale save also removed ~1,000 characters A had written a minute before (4,768 → 3,782 characters).
  • In 3 weeks of logs we counted 26 saves made from a copy older than another user's latest save, on 7 work items. On one item, two users overwrote each other every few seconds for about a minute.
  • The description history since 2025-08 contains more cases where an image added by one user disappeared after another user's save.
Steps to reproduce
  1. Open the same work item in two browsers as user A and user B.
  2. As A, add an image (or a paragraph) to the description and wait for the autosave.
  3. As B, without reloading, change anything in the description.
  4. Reload: A's image or paragraph is gone. The version history shows it existed in A's version.

Expected: A's change is kept (merged), or B is at least told that the description changed and is not allowed to silently overwrite it.

Possible directions
  1. Make work item descriptions collaborative through the live server, like pages (description_binary already exists on Issue). This removes the problem at its root.
  2. Optimistic concurrency as a smaller step: the client sends the version it started from (e.g. updated_at or a hash of description_html), the API returns 409 when it is outdated, and the editor refetches and reapplies the user's edit instead of overwriting.
  3. Server-side merge as a stopgap. On our instance we now keep, per user and work item, the description the editor last loaded or saved. When the stored description changed since then, we apply the other users' changes onto the incoming HTML with a block-level 3-way merge (recursing into lists). If both sides changed the same block, both versions are kept. This has stopped the image loss for us. I'm happy to share the patch if it helps, but option 1 or 2 is clearly the better long-term fix.

Related: #9779 (realtime work-item updates for list/board views).

Environment

Production

Browser

Google Chrome

Variant

Self-hosted (Community)

Version

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

Dominant language
TypeScript
Stars
60.7k
Forks
6k
Avg merge
1d 11h
Merged PRs (30d)
79

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from makeplane/plane

All issues in makeplane/plane

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.