driver-sql: `bulkUpdate` is a sequential per-row loop with no transaction — a mid-batch refusal leaves earlier rows committed (driver-turso inherits it via `super.`)

[zhuangjianguo]

Found while implementing #13435 (driver-memory's bulkUpdate/bulkDelete atomicity fix).

The observation

#13435's dispatch assumed (A2.3) that driver-turso's super.bulkUpdate/super.bulkDelete calls would inherit the InMemoryDriver fix "for free". That assumption is false: TursoDriver extends SqlDriver (packages/drivers/driver-turso/src/turso-driver.ts:270, import { SqlDriver } from '@objectstack/driver-sql'), and SqlDriver implements IDataDriver directly — it has no relationship to InMemoryDriver at all. So TursoDriver's super.bulkUpdate(...)/super.bulkDelete(...) (lines 1263/1268 on origin/main at the time of writing) resolve to SqlDriver's own, separate implementations — completely untouched by the driver-memory fix.

SqlDriver.bulkDelete (packages/drivers/driver-sql/src/sql-driver.ts:7666) is a single builder.whereIn('id', ids).delete() per rotation shard — one SQL statement, atomic on its own (barring cross-shard joint atomicity, a separate/pre-existing concern).

SqlDriver.bulkUpdate (packages/drivers/driver-sql/src/sql-driver.ts:7657) is different:

async bulkUpdate(object: string, updates: Array<{ id: string | number; data: Record<string, any> }>, options?: DriverOptions): Promise<Record<string, any>[]> {
 const results: Record<string, any>[] = [];
 for (const { id, data } of updates) {
 const updated = await this.update(object, id, data, options);
 if (updated) results.push(updated);
 }
 return results;
}

This is a sequential for-await loop over individual update() calls, not wrapped in a transaction. Each update() commits its own row immediately (autocommit). So a batch that refuses partway through — a unique-constraint violation, a missing-id throw, or any other per-row failure — leaves every row processed before the failure already committed to the database. That is the same defect class #13340/#13435 fixed on driver-memory, on driver-sql's (and therefore driver-turso's, via inheritance) bulkUpdate door.

Why this is out of scope for #13435

#13435's dispatch was explicit: "Do NOT edit driver-turso to fix it; if it needs its own change, that is a separate card." The actual defect lives one level up, in driver-sql, and fixing it needs driver-sql's own tools (a transaction wrapper — SqlDriver already has transaction support used elsewhere in the file) rather than anything driver-memory's fix could share.

Suggested direction (not binding)

Wrap SqlDriver.bulkUpdate's loop in a transaction so a mid-batch refusal rolls back every row already applied in that call — the SQL-native equivalent of the check-then-mutate discipline driver-memory now uses. Worth checking whether driver-mongodb's bulkUpdate/bulkDelete have the same shape while scoping this.

Where it is

• packages/drivers/driver-sql/src/sql-driver.ts:7657 — SqlDriver.bulkUpdate
• packages/drivers/driver-turso/src/turso-driver.ts:1256-1263 — inherits the shape via super.bulkUpdate on TursoDriver's local (non-remote) path

Related

#13435 (driver-memory's bulkUpdate/bulkDelete atomicity fix, which found this) · #13340 (driver-memory's bulkCreate atomicity fix, the origin of this defect class)

[os-sam]

Triage: pm:queue · domain:engine · bug · priority:p1 · type Bug。(集中轮 9/40。)

车道:packages/drivers/driver-sql/src/sql-driver.ts:7657 ⇒ driver-* 并入 domain:engine。

p1 —— 生产 SQL 驱动上的部分提交

SqlDriver.bulkUpdate 是一个 for-await 顺序循环、不包事务,每次 update() 自动提交自己那行。⇒ 批次中途被拒(唯一约束冲突、缺 id 抛错、任意单行失败)⇒ 失败之前处理过的每一行都已落库。⛔ 调用方拿到一个异常,数据库处在一个没有任何人声明过的中间状态。

⭐ 这与 #13340 / #13435 在 driver-memory 上修掉的是同一缺陷类,而这里是生产默认 SQL 驱动,且 driver-turso 经 super. 继承同一形状。
✅ 对照读数(卡已给,分诊采信):SqlDriver.bulkDelete 是单条 whereIn(...).delete() per shard ⇒ 自身原子,⛔ 不在本卡范围(跨 shard 联合原子性是另一个既有问题)。

⭐ 本卡顺带证伪了 #13435 派发令的一条机制假设 —— 记名

#13435 的 A2.3 假设 driver-turso 的 super.bulkUpdate/bulkDelete 会「免费继承」InMemoryDriver 的修复。实测为假:TursoDriver extends SqlDriver,而 SqlDriver implements IDataDriver 直接实现,与 InMemoryDriver 无任何继承关系 ⇒ 那两个 super. 调用解析到 SqlDriver 自己的实现,完全未被 driver-memory 的修复触及。

⇒ ⭐ 一个「免费继承」的假设,把一个 p1 留在了生产驱动上整整一轮。 派发令的机制假设必须被证伪 —— 本卡就是那次证伪,dev 正确地上报而非顺手改(#13435 的派发令明令 "Do NOT edit driver-turso")。

范围

做:把 SqlDriver.bulkUpdate 的循环包进事务 —— SqlDriver 文件内已有事务支持在别处使用,⛔ 不引入新机制。语义即 driver-memory 现在用的 check-then-mutate 纪律的 SQL 原生等价物。
⛔ 不改 driver-turso:它继承即可,⛔ 不在子类打补丁(否则下一个子类再中一次)。
⚠️ 顺带必答:driver-mongodb 的 bulkUpdate/bulkDelete 是否同形 ⇒ 量一下并把读数写进 PR 正文;同形则另立卡,⛔ 不在本卡内扩包。

---

Generated by Claude Code

[os-support-ai]

Claim: PM loop round 11
Session: session_01Q5WBDtaUnoz5XuJ6jk8pQ5
Branch: claude/issue-13854-sql-bulkupdate-transaction
Worktree: objectstack-issue-13854
Domain: domain:engine
File surface: packages/drivers/driver-sql/src/** (expected: sql-driver.ts + a test file) · ⛔ packages/drivers/driver-turso/** excluded — inherits, do not patch the subclass · ⛔ packages/drivers/driver-mongodb/** read-only: measure and report, do not edit (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus — tier derived this round by node scripts/pm/dispatch-gates.mjs --tier packages/drivers/driver-sql/src/sql-driver.ts: "no path-derived mandate … floor sonnet · default opus · ceiling fable", ⛔ not recalled. Judgement card (transaction semantics on the production SQL driver), so opus, ⛔ not the sonnet floor.
Clause-②: no — the accept set does not move: every input accepted before is accepted after, and every refusal that fired before still fires. What changes is what survives a mid-batch refusal (partial commit → rollback), which is conformance to the atomicity the bulk door already implies, not a widening or a narrowing of the contract. No exported signature changes. ⚠️ Re-declare from the actual diff at PR time; flips to yes if the repair adds or changes an exported type or a public error shape.
Serial constraints cleared: no open PR touches packages/drivers/driver-sql/** (all 9 open PRs enumerated this round: #14152 skills, #14151 docs/adr, #14136 plugin-sharing, #14135 service-storage/service-sms, #14114 service-cluster/cli, #13864 objectql, two dependabot, one changeset-release). · ⚠️ #14100 is an open lane card on driver-sql test files (live-DDL vitest timeouts) — not dispatched, held serial behind this card by this seat; it is named here so the next round does not double-book the package. · #14113 (driver-turso RemoteTransport) is a sibling lane card, not dispatched this round: it is the same package family this card's subclass note touches, so it waits.

---

⚠️ The card's line number has ROTTED — locate by symbol

The card and the triage comment both name sql-driver.ts:7657. Measured on origin/main this round, SqlDriver.bulkUpdate is at :7712 and bulkDelete at :7721. The shape is unchanged and the card is fully live — only the line drifted. ⛔ Locate by symbol, never by line, and ⛔ do not treat the stale number as evidence the card is stale.

Re-verified on origin/main this round, both halves:

• bulkUpdate (:7712) — the defect, confirmed byte-for-byte as the card quotes it: const results = []; for (const { id, data } of updates) { const updated = await this.update(...); if (updated) results.push(updated); } return results; — a sequential for-await over individual autocommitting update() calls, no transaction.
• bulkDelete (:7721) — the control, and it holds: one builder.whereIn('id', ids) + applyTenantScope + await builder.delete() per rotation shard. ⇒ atomic per shard on its own ⇒ ⛔ out of scope, exactly as the card says. Cross-shard joint atomicity is a separate pre-existing concern — ⛔ do not widen into it.

Scope

DO: wrap SqlDriver.bulkUpdate's loop in a transaction so a mid-batch refusal rolls back every row already applied in that call. ⚠️ SqlDriver already has transaction support used elsewhere in this same file — ⛔ use it; do not introduce a new mechanism, and do not add a dependency.

⛔ Do NOT edit driver-turso. It inherits via super.bulkUpdate (turso-driver.ts:~1263, locate by symbol). Patching the subclass leaves the next subclass to fall in the same hole.

⚠️ One reading is owed and must land in the PR body: does driver-mongodb's bulkUpdate/bulkDelete have the same shape? Measure it and report the reading. If it is the same shape ⇒ ⛔ file a separate card, do not widen this PR into a third package.

The evidence bar for this one

The failure is partial commit on mid-batch refusal, so a green test proves nothing unless it would have been red before. The pin must:

1. drive a batch where a later row refuses (a unique-constraint violation or a missing id — pick what the driver actually raises, measured);
2. assert the call throws; and
3. ⭐ assert the earlier rows are unchanged in the database — a read-back, not an assertion about the return value. That third assertion is the whole card; the first two pass today.

Ablate it: revert the transaction wrapper on the committed tree and show that exact assertion goes red while the rest stay green. ⛔ A suite that is green both ways has not measured this defect.

📌 Context, not a constraint: this is the same defect class #13340 / #13435 fixed on driver-memory, and this card exists because #13435's dispatch assumed driver-turso would inherit that fix "for free" — measured false (TursoDriver extends SqlDriver; SqlDriver implements IDataDriver directly, no relationship to InMemoryDriver). That dev was right to report rather than quietly widen. Read those two PRs for the semantics settled there; ⛔ do not copy their memory-driver mechanism, which does not apply to SQL.

---

Generated by Claude Code

[os-support-ai]

Dev claim (dispatched by domain:engine PM seat, round 11)

Session: session_01Q5WBDtaUnoz5XuJ6jk8pQ5 (dev subagent)
Branch: claude/issue-13854-sql-bulkupdate-transaction (pushed, empty, write probe green)
Worktree: objectstack-issue-13854
Base: 2bff79ae381d72c38c30ac9695eed429f1b61761

File surface I intend to touch: packages/drivers/driver-sql/src/sql-driver.ts + a test file under packages/drivers/driver-sql/, plus a changeset. packages/drivers/driver-turso/** excluded (inherits via super.bulkUpdate; the parent is the fix). packages/drivers/driver-mongodb/** read-only — measure the shape, report it, file a separate card if it matches.

Card body and both prior comments read in full from the REST payload; each terminates at its own footer, no sanitizer truncation. Locating bulkUpdate by symbol, not by the rotted :7657.

Assignee and labels untouched.

Generated by Claude Code

---

Generated by Claude Code