Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#9,995 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@NadaaFarook ya está trabajando en esto.

Desde el 13/10/2026.

  • #9999 de @NadaaFarook — abierto

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
django, python, react, typescript
Área
api, backend, frontend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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)

Lenguaje dominante
TypeScript
Estrellas
61.5k
Forks
6.2k
Merge medio
1 d 18 h
PR fusionados (30 d)
79

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de makeplane/plane

Todos los issues de makeplane/plane

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.