Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#9,995 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@NadaaFarook ci sta già lavorando.

Dal 13/10/2026.

  • #9999 di @NadaaFarook — aperta

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
django, python, react, typescript
Ambito
api, backend, frontend

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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)

Lingua principale
TypeScript
Stelle
61.1k
Fork
6.1k
Merge medio
1g 11h
PR unite (30g)
79

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di makeplane/plane

Tutte le issue di makeplane/plane

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.