René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"sqlite: backup() rejects with \"not an error\" when its first step returns SQLITE_BUSY or SQLITE_LOCKED","articleBody":"### Version\n\nv22.22.1, v24.21.0\n\n### Platform\n\n```text\nDarwin 27.0.0 arm64\n```\n\n### Subsystem\n\nsqlite\n\n### What steps will reproduce the bug?\n\nRun this script as `node repro.mjs`, then as `node repro.mjs --no-overlap`:\n\n```js\nimport { DatabaseSync, backup } from \"node:sqlite\";\nimport fs from \"node:fs\";\nimport os from \"node:os\";\nimport path from \"node:path\";\n\nconst dir = fs.mkdtempSync(path.join(os.tmpdir(), \"sqlite-backup-\"));\nconst db = new DatabaseSync(path.join(dir, \"src.db\"));\ndb.exec(\"PRAGMA journal_mode = WAL; CREATE TABLE t (x BLOB)\");\nconst insert = db.prepare(\"INSERT INTO t VALUES (randomblob(4000))\");\nfor (let i = 0; i \u003c 300; i++) insert.run();\n\nconst overlap = process.argv[2] !== \"--no-overlap\";\nconst results = {};\nfor (let i = 0; i \u003c 20; i++) {\n  let job;\n  if (overlap) {\n    // Keep a write transaction open briefly so the backup worker can attempt its first step.\n    db.exec(\"BEGIN IMMEDIATE\");\n    insert.run();\n    job = backup(db, path.join(dir, `copy-${i}.db`));\n    const until = Date.now() + 30;\n    while (Date.now() \u003c until);\n    db.exec(\"COMMIT\");\n  } else {\n    job = backup(db, path.join(dir, `copy-${i}.db`));\n  }\n  try {\n    await job;\n    results.ok = (results.ok ?? 0) + 1;\n  } catch (e) {\n    const key = `${e.code} errcode=${e.errcode} message=${JSON.stringify(e.message)}`;\n    results[key] = (results[key] ?? 0) + 1;\n  }\n}\nconsole.log(process.version, overlap ? \"overlap\" : \"no overlap\", results);\ndb.close();\nfs.rmSync(dir, { recursive: true, force: true });\n```\n\n### How often does it reproduce? Is there a required condition?\n\nIn my tests on each version above, all 20 backups failed with overlap enabled, and all 20 succeeded with `--no-overlap`. The reproducer holds a write transaction open on the same source connection for 30 ms after starting the backup. Reproduction depends on the worker attempting its first step during that interval.\n\n### What is the expected behavior? Why is that the expected behavior?\n\nThe backup should reschedule a first step that returns `SQLITE_BUSY` or `SQLITE_LOCKED`, just as it reschedules later steps when pages remain, allowing it to finish after the write transaction commits. `SQLITE_BUSY` and `SQLITE_LOCKED` from `sqlite3_backup_step()` are retryable according to the SQLite documentation. If Node does reject, the error should carry the real result code (5 or 6), not 0.\n\n### What do you see instead?\n\n```text\nv22.22.1 overlap { 'ERR_SQLITE_ERROR errcode=0 message=\"not an error\"': 20 }\nv22.22.1 no overlap { ok: 20 }\nv24.21.0 overlap { 'ERR_SQLITE_ERROR errcode=0 message=\"not an error\"': 20 }\nv24.21.0 no overlap { ok: 20 }\n```\n\nThe promise rejects with `ERR_SQLITE_ERROR`, `errcode: 0` and the message \"not an error\".\n\n### Additional information\n\nThe cause appears to be in `BackupJob::AfterThreadPoolWork` in `src/node_sqlite.cc` (the same logic is on `main`):\n\n1. A step result of `SQLITE_BUSY` or `SQLITE_LOCKED` is not treated as an error at first.\n2. The job is rescheduled only when `sqlite3_backup_remaining()` is non-zero. The count starts at 0 and can remain 0 when the first step returns `SQLITE_BUSY` or `SQLITE_LOCKED` before updating it.\n3. So when the first step returns `SQLITE_BUSY` or `SQLITE_LOCKED`, the job is not rescheduled. Because the status is not `SQLITE_DONE`, `HandleBackupError(resolver)` runs. It builds the error from the destination connection, which has no error, so the result is errcode 0, \"not an error\".\n\nA possible fix: reschedule the work whenever the step returned `SQLITE_BUSY` or `SQLITE_LOCKED`, whatever the remaining page count. If the final `backup_status_ != SQLITE_DONE` rejection path is retained, pass `backup_status_` to `HandleBackupError` there, as the earlier fatal-error branch already does.\n\nA possible workaround for this failure is to retry the backup after the overlapping write transaction ends, using a bounded retry policy and checking for both `code === 'ERR_SQLITE_ERROR'` and `errcode === 0`.\n","author":{"url":"https://github.com/EminUZUN","@type":"Person","name":"EminUZUN"},"datePublished":"2026-10-15T13:34:17Z","url":"https://github.com/nodejs/node/issues/66760"}