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

bug: a failed run() rolls back a transaction it did not open (Android)

Abierto
  • ¿Algo no está bien?
#700 1 comentario 1 reacción 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
72/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
android, java, sqlite
Área
database, mobile

Línea de trabajo

Comienza en Database.java con el bloque finally de run() y, a continuación, compara la limpieza correspondiente en execute() y executeSet(). Reproduce la secuencia de Android del issue y verifica que un inicio de transacción fallido deja activa la transacción existente, conserva tx-write-1 y permite que el commit posterior tenga éxito.

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

Descripción

Plugin version:

7.0.3

Platform(s):

Android (reproduced on a device). Not about web — on web the same collision fails earlier and louder.

Current behavior:

When run() is called with transaction: true while an explicit transaction (beginTransaction()) is already open, it correctly fails with Already in transaction — but on the way out it rolls back the transaction it collided with, which it did not open. The rows that transaction had already written are silently discarded, statements issued afterwards execute outside any transaction and auto-commit, and the eventual commitTransaction() fails.

Measured on a device:

intruder:                            "Run: Failed in beginTransactionAlready in transaction"
transactionStillActiveAfterIntruder: false     <- nobody asked for this
secondWriteInsideTransaction:        "ok"      <- now running outside any transaction
commit:                              "CommitTransaction: Cannot perform this operation
                                      because there is no current transaction."
finalRows:                           ["tx-write-2"]   <- tx-write-1 is gone

tx-write-1 was written inside the explicit transaction before the intruding call arrived. It is gone, and nothing in the log says a rollback happened.

Expected behavior:

A call that fails to begin a transaction should leave transaction state untouched. Cleanup should roll back only a transaction that the same call opened — not whatever transaction happens to be open on the connection.

The Already in transaction error itself is correct and useful; the collateral rollback is the bug.

Steps to reproduce:

Run against a throwaway database on Android. No app framework needed — this is the raw plugin API.

Related code:

const sqlite = window.Capacitor.Plugins.CapacitorSQLite;
const database = "reprobug";

await sqlite.createConnection({ database, encrypted: false, mode: "no-encryption", version: 1, readonly: false });
await sqlite.open({ database, readonly: false });
await sqlite.execute({ database, statements: "CREATE TABLE IF NOT EXISTS t (label TEXT);", transaction: false, readonly: false, isSQL92: true });
await sqlite.run({ database, statement: "DELETE FROM t;", values: [], transaction: true, readonly: false, returnMode: "no" });

// An explicit transaction writes one row.
await sqlite.beginTransaction({ database });
await sqlite.run({ database, statement: "INSERT INTO t (label) VALUES ('tx-write-1');", values: [], transaction: false, readonly: false, returnMode: "no" });

// An unrelated write arrives, asking for its own transaction. It fails, as documented.
try {
  await sqlite.run({ database, statement: "INSERT INTO t (label) VALUES ('intruder');", values: [], transaction: true, readonly: false, returnMode: "no" });
} catch (error) {
  console.log("intruder:", error.message);           // Already in transaction
}

// The explicit transaction is no longer active, and nobody ended it.
console.log("still active:", (await sqlite.isTransactionActive({ database })).result);   // false

await sqlite.run({ database, statement: "INSERT INTO t (label) VALUES ('tx-write-2');", values: [], transaction: false, readonly: false, returnMode: "no" });
try {
  await sqlite.commitTransaction({ database });
} catch (error) {
  console.log("commit:", error.message);             // no current transaction
}

const rows = await sqlite.query({ database, statement: "SELECT label FROM t;", values: [], readonly: false });
console.log("rows:", rows.values.map((r) => r.label)); // ["tx-write-2"] — tx-write-1 lost

The cleanup lives in Database.java, in the finally of run() (and the same shape in execute() / executeSet()):

} finally {
    if (_db != null && transaction && _db.inTransaction()) rollbackTransaction();
}

_db.inTransaction() reports engine state, not ownership, so a call whose own beginTransaction() threw still satisfies the condition and rolls back the transaction belonging to somebody else. Tracking whether this invocation actually opened a transaction — and only rolling back in that case — would fix it.

Other information:

This is not the queueing discussion from #215 and #258, which are about whether the plugin should serialize concurrent writes. Even accepting that the caller must serialize, a failed call should not destroy another transaction's committed work. The failure mode is what makes it worth separating: Already in transaction is visible, but the lost rows are not — no error, no log, and the data is simply missing.

How it shows up in practice: any second writer that isn't aware a transaction is open — a sync engine applying server records, a log writer, an analytics flush — lands mid-transaction and takes the transaction down with it. docs/SQLiteTransaction.md tells callers to pass transaction: false inside a transaction, which is the right advice for code that knows about the transaction; the problem is code that doesn't.

Note that with transaction: false the collision is quieter but still lossy: the write silently joins the open transaction and is rolled back with it.

Workaround, for anyone else who lands here: serialize units of work in the caller, so a statement or a whole transaction is exclusive. A promise chain around every write and every transaction is enough. For Kysely users specifically, locking in the dialect's acquireConnection() and releasing in releaseConnection() does it, since Kysely holds one connection for the duration of a transaction.

Device: Xiaomi 24117RN76G, Android 16 (SDK 36).

Capacitor doctor:

Latest Dependencies:

  @capacitor/cli: 8.5.0
  @capacitor/core: 8.5.0
  @capacitor/android: 8.5.0
  @capacitor/ios: 8.5.0

Installed Dependencies:

  @capacitor/cli: 8.5.0
  @capacitor/ios: 8.5.0
  @capacitor/android: 8.5.0
  @capacitor/core: 8.5.0

[success] Android looking great! 👌
Lenguaje dominante
Swift
Estrellas
661
Forks
158
Sin PR fusionados en 30 d

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 capacitor-community/sqlite

Todos los issues de capacitor-community/sqlite

Issues similares

Más issues de Swift

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.