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

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):

• 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)