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

🐛 Bug Report: Transaction upsert ignores rowId and creates a new row

Abierto Apto para principiantes
  • ¿Algo no está bien?
#14,178 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@HarshMN2345 ya está trabajando en esto.

Desde el 7/10/2026.

  • #14197 de @HarshMN2345 — abierto

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
82/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
php, postgresql
Área
backend-api-design, databases

Línea de trabajo

Empieza por src/Appwrite/Platform/Modules/Databases/Http/Databases/Transactions/Update.php, especialmente handleUpsertOperation() alrededor de las líneas 678–682, y traza cómo el documentId de la operación llega a la llamada de upsert. Usa los pasos de reproducción para comprobar que al confirmar un upsert se actualiza el ID de fila especificado, y que se usa un ID de fila no existente para la fila creada.

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

Descripción

product / databases
👟 Reproduction steps
  1. Table with columns status (string) and n (integer); create row up1 with status = "open", n = 0.
  2. POST /v1/tablesdb/transactions → transaction T.
  3. Stage an upsert the way the API documents operations (row ID in rowId, values in data): 
    {"operations": [{"action": "upsert", "databaseId": "db", "tableId": "t", "rowId": "up1", "data": {"status": "done", "n": 1}}]}
  4. PATCH /v1/tablesdb/transactions/T with commit: true → 200.
  5. Read row up1, and list rows with status = "done".
👍 Expected behavior

Row up1 now has status = "done", n = 1 (or, for a non-existing rowId, a row with that ID is created).

👎 Actual Behavior
  • Row up1 is unchanged (status = "open", n = 0).
  • Instead a new row with a generated ID (e.g. 6ac5371741b960276721) with status = "done", n = 1 was created.
  • For a non-existing rowId the same happens: no row with that ID, but a new row with a random ID.
  • Staging returns 201, commit returns 200 – there is no error.

Adding "$id": "up1" inside data makes it work, so only the rowId field of the operation is ignored. In a sync that uses transactional upserts this silently produces duplicates and never updates the intended rows (30 of 30 attempts in our test).

Cause: handleUpsertOperation() builds the document from data only and never sets the operation's documentId (Transactions/Update.php L678–L682):

$doc = $dbForProject->upsertDocument(
    $collectionId,
    new Document($data),
);

$documentId is passed to the method and used for the "dependent" branch (row already touched earlier in the same transaction), but not here. main has the same code.

🎲 Appwrite version

2.3.0

💻 Operating system

Linux (Debian 12), Docker

🧱 Your Environment

Self-hosted Appwrite 2.3.0, Postgres adapter (PostgreSQL 18), two API nodes.

💡 Suggested fix

Set the ID before upserting, e.g. new Document(\array_merge($data, ['$id' => $documentId ?? $data['$id'] ?? ID::unique()])), and reject an operation where rowId and data.$id differ.

👀 Have you spent some time to check if this issue has been raised before?
  • I checked and didn't find a similar issue
🏢 Have you read the Code of Conduct?
  • I have read the Code of Conduct
Lenguaje dominante
PHP
Estrellas
57.6k
Forks
5.8k
Merge medio
17 h 32 min
PR fusionados (30 d)
397

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 appwrite/appwrite

Todos los issues de appwrite/appwrite

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.