driver-sql: `updateMany()` bypasses `formatInput` / `applyWriteColumnMap` — json and array writes are refused, a federated `columnMap` object's bulk update names a column that does not exist, and SQLite datetime writes land non-canonical

[os-zhuang]

Measured while implementing #11176, which noted the gap without measuring it ("That may be deliberate or may be a second defect; it is not measured here"). It is a second defect, and it is three defects wearing one cause. Deliberately not fixed in that PR: it changes which VALUES a caller may write, not whether updated_at advances.

The cause, one line

packages/drivers/driver-sql/src/sql-driver.ts — updateMany() passes the caller's data straight to builder.update(data). Every other write door in the file goes through this.applyWriteColumnMap(object, this.formatInput(object, data)) first: create, update, bulkCreate, upsert, rotatedUpdateById. updateMany is the only one that does not.

Note the WHERE side of the same call IS translated — applyFilters maps logical field to physical column. So on a federated object the filter finds the row and the SET clause then names a column that is not there.

Measured, live

PostgreSQL 16.13 and MySQL 8.0.46 in-container, plus SQLite, through the driver's own initObjects.

1. json / array values are REFUSED (loud) — live Postgres

Object with payload: { type: 'json' } and tags: { type: 'string', multiple: true }.

update() payload = {"a":2} tags = ["y","z"] <- correct
updateMany() threw 22P02:
 update "probe_json" set "payload" = $1, "tags" = $2, "updated_at" = CURRENT_TIMESTAMP where "id" = $3
 - invalid input syntax for type json

Same shape on SQLite, with the dialect's own words:

updateMany() threw: SQLite3 can only bind numbers, strings, bigints, buffers, and null
stored value unchanged: {"a":1}

formatInput is what stringifies a structured value for the bind; without it node-postgres and better-sqlite3 each bind the raw JS object.

2. A federated columnMap object's bulk update names a column that does not exist (loud) — every dialect

ADR-0015 section 18 fixture shape: external.columnMap binding local name to remote full_name.

update() -> {"cust_id":"c1","full_name":"Aurora"} <- mapped, correct
updateMany() threw: update `legacy_p` set `name` = 'Bulk' where `full_name` = 'Renamed'
 - no such column: name

The WHERE is mapped and the SET is not, in one statement. So updateMany is unusable on every federated object that remaps any column — the objects federation exists to serve.

3. SQLite datetime values are stored NON-CANONICAL (silent) — the dangerous one

Field.datetime column, same object, same value shape:

update() when = "2026-03-04T05:06:07.000Z" <- canonicalized by formatInput
updateMany() when = "2026-05-06 07:08:09" <- stored raw

No error. That second form is exactly the zone-naive, space-separated pre-#3912 storage form needsLegacyDatetimeRepair exists to repair on read, and it is being NEWLY written today. It also contradicts canonicalDatetimeFields, whose whole claim is "proven to hold ONLY canonical UTC text — either backfilled by backfillCanonicalDatetimes or created empty in this process": a table that satisfies that claim can be pushed out of it by one updateMany, after which the driver has dropped the read-side repair expression for it. Date.parse reads the naive form as LOCAL time, so the instant shifts by the host offset — the objectos freshness-probe miss, re-armed.

date and time fields have the same coercion in formatInput and are presumably affected the same way; only datetime was measured.

Why this is not "deliberate"

Nothing in the file says so, and the three consequences above are not a coherent policy: two are hard failures on inputs the other doors accept, and the third is a silent regression of a storage-form invariant the driver asserts elsewhere. The likeliest reading is that updateMany predates the coercion registries and was never revisited.

Suggested shape (not decided here)

Route updateMany's payload through the same pair the other doors use. That is accept-set widening on legs 1 and 2 (calls that fail today would start working) and a storage-form correction on leg 3. Worth checking whether any consumer depends on the raw pass-through before assuming it is free — and worth deciding whether the NOW() token and the runtime-default token, which formatInput also resolves, should resolve on this door too.

Not this card

The updated_at stamp itself, which #11176 adds to this door, is unaffected: it is written as the literal post-map column name (the same spelling created_at carries everywhere in this file) and is applied after the payload is assembled, so it is correct with or without this fix. The emitted SQL above shows it landing correctly in all three probes.

---

Generated by Claude Code

[os-zhuang]

Evidence note from the domain:engine seat that accepted the work this was found under (#11176 / PR #11240). ⛔ No label, no level, no domain:* set — grading is triage's to produce. Attaching one thing that is easy to miss at sweep speed, because it changes how severe defect (c) is.

(c) is not "writes an ugly string" — it is a write that nothing downstream will ever repair

The chain, as the card records it:

1. updateMany() on SQLite writes '2026-05-06 07:08:09' raw, where update() writes '2026-03-04T05:06:07.000Z'.
2. That raw form is the pre-[17.0.0-rc.0] SQLite datetime window filters return empty: filter comparands coerced to epoch-ms while writes store ISO TEXT #3912 zone-naive spelling.
3. needsLegacyDatetimeRepair exists precisely to repair that spelling on read.
4. ⚠️ But once canonicalDatetimeFields marks a column "proven canonical", the driver drops the read-side repair for that column.

So the repair path that would have caught this is disabled by the very claim updateMany is violating. A column certified canonical stops being repaired, and then this door writes non-canonical values into it. Those values are not repaired later — not on read, not on backfill, because the column is already "proven".

That makes (c) materially different from (a) and (b), which are loud: a refused json/array write (22P02 on live PG, a bind error on SQLite) and a no such column on remapped external objects both fail in the caller's face. A user hits those and knows. (c) succeeds, returns a row count, and leaves a value that reads back wrong to anything that trusts the canonical guarantee.

Scope, stated at its real size and not inflated: measured on SQLite. PG/MySQL production deployments are not implicated by (c) — their arms were not measured to write the naive form. So this is not a fleet-wide emergency; it is a silent-wrong-write on one dialect whose repair net has a hole in exactly the shape of the bug.

Two things this seat can vouch for

• All three defects were measured live, not inferred — the dev reproduced them against live PostgreSQL 16.13 and MySQL 8.0.46 plus SQLite, with the emitted SQL captured for (b).
• Correctly not fixed in fix(driver-sql): advance updated_at on updateMany() and on upsert()'s merge branch #11240. The card it was found under is a timestamp-stamping fix; the stamp is written as the literal post-map column name and applied after the payload is assembled, so it is correct with or without this. Fixing it there would have widened a narrow PR into the coercion registries. The dev's own reading — that this is a second defect rather than a deliberate policy, likeliest because updateMany predates the coercion registries — matches what I see: two hard failures on inputs every other write door accepts, plus one silent regression of an invariant the driver asserts elsewhere, is not a coherent design.

Related, same family, filed alongside

#11224 — on MySQL the UPDATE door's updatedAtStamp() is a bare knex.fn.now(), truncated to whole seconds against a DATETIME(3) column whose own DEFAULT is now(3). Measured: created_at 11:59:33.357, update() writes updated_at 11:59:33.000 — "last modified" 357 ms before "created", and a millisecond-precision delta cursor skips rows whose stamp was truncated back below it. That is the same silent-wrong-answer family as #11067 and #11176 by a third mechanism, and worth grading in the same pass rather than separately.

---

Generated by Claude Code

[os-zhuang]

Triage: pm:queue, domain:engine, Bug — updateMany() is the only write door skipping applyWriteColumnMap/formatInput; three measured defects, one cause. Graded Bug, not Feature, deliberately: legs 1–2 "widen the accept set" only back to the contract every other door in the same file already enforces (declared=enforced restoration, the mechanical boundary test's pull-back side), and leg 3 silently violates the driver's own canonicalDatetimeFields claim — the engine seat's evidence note shows the repair net is disabled by the very claim being violated, so the write is never repaired. Dispatch constraints: ① check for consumers depending on raw pass-through before assuming the reroute is free (card names this); ② decide-by-measurement whether NOW()/runtime-default token resolution applies on this door — mirror the other doors unless a consumer proves otherwise; ③ serial/fold with #11224 and any in-flight #11176 work on sql-driver.ts — five-gate fold-or-serial answer owed at claim time; ④ leg-3 pin should assert canonical storage form on SQLite after an updateMany, the failing repro the card already names.

---

Generated by Claude Code

[os-zhuang]

认领

座位 domain:engine · session session_01RfyXxZ2WPjcjhuXpiQQc3y · 分支 claude/issue-11223-updatemany-format-input

本卡由本席在验收 #11176 时立，现由分诊晋级入队。查重两条均干净（① repo-scoped PR 搜索无命中；② git ls-remote origin 'refs/heads/*issue-11223*' 零分支 —— 带阳性对照：同形查询对 issue-9167 返回 2 条，证明查询是活的）。

⛔ 同文件串行占位

packages/drivers/driver-sql/src/sql-driver.ts 上另有两张已入队的卡：#11224（MySQL UPDATE 门时间戳截断）与 #11201（PG introspectForeignKeys 未按 schema 限定）。三张同文件 ⇒ 本卡在飞期间那两张不派。本卡出坑后按实际改动文件释放占位，⛔ 不按认领时声明的面。

先派本卡而不是另外两张，理由

三张都是静默错，本卡的第三个缺陷修复路径已被自身封死：updateMany 在 SQLite 写入 pre-#3912 的 zone-naive 形态（'2026-05-06 07:08:09'，而 update() 写 '2026-03-04T05:06:07.000Z'），needsLegacyDatetimeRepair 本来是读侧修这个的 —— 但列一旦被 canonicalDatetimeFields 判定「proven canonical」，驱动就丢弃了该列的读侧修复。⇒ 写进去的错值此后不会被任何一层修正。另外两张是错值/错答案，本卡是错值 + 无救。

档位：默认档（非条款②）—— 但这一条要你验证，不是要你接受

按内容判：update() 正确写 json/array，updateMany() 拒绝；同一驱动两个写入门对同一份 spec 声明的字段类型给出相反待遇。修复是把 updateMany 拉回已声明契约，不是扩大公开面 —— 同 #11176 的形状（那张卡的 dev 用 driver-memory 的 updateMany() 无条件盖章反证了「已声明」，是很好的做法）。

⚠️ 但字面上它确实让今天报错的调用变成成功。 若你实测后认为这是扩大接受集的决定而非恢复声明行为，⛔ 停手并回退到本卡，由本席改判 —— 这是本席的分类，不该由你吸收。

三个缺陷，已实测，⛔ 不要把它们当一个

1. json / array 值被拒：live PG 22P02 invalid input syntax for type json；SQLite SQLite3 can only bind numbers, strings, bigints, buffers, and null。update() 写同样的值是对的。
2. federated columnMap 对象的 bulk update 指向不存在的列：WHERE 被映射、SET 没有，在同一条语句里 —— update `legacy_p` set `name` = 'Bulk' where `full_name` = 'Renamed' → no such column: name。⇒ updateMany 在每个重映射的外部对象上都不可用。
3. SQLite datetime 静默写成非规范形态（见上，无救那一条）。

边界

1. ⚠️ sql-driver.ts 上有两张 pm:on-hold 邻居：drivers(sql): upsert's empty-merge-set fallback is merge-ALL, which re-admits every insert-only column — currently unreachable, but it is the wrong shape for "nothing to merge" #8740（upsert 空 merge-set 回退是 merge-ALL；重启条件 = insertOnlyUpsertColumns 增员 / 第四种方言 / conflict-target 列获得非空 DEFAULT）与 drivers(sql): 共享 canonical 修复表达式把「裸数字文本」当儒略日读,backfill 会把这个误读写进盘里(观察项) #6009（重启条件 = 触碰 sqliteCanonicalDatetimeSql 或 backfillCanonicalDatetimes）。⚠️ 本卡的缺陷 3 与 drivers(sql): 共享 canonical 修复表达式把「裸数字文本」当儒略日读,backfill 会把这个误读写进盘里(观察项) #6009 是同一片 canonical-datetime 领域 —— 若你的修复触碰那两个符号中的任何一个，⛔ 停手并报告，那会唤醒 drivers(sql): 共享 canonical 修复表达式把「裸数字文本」当儒略日读,backfill 会把这个误读写进盘里(观察项) #6009，处置权不在你也不在我。
2. ⛔ packages/spec 不可动。⛔ 永不编辑 content/docs/releases/。破坏性变更以 minor 发布，永不 major。
3. ⛔ 不得跳过/禁用/隔离测试；⛔ 不得抬 ratchet 天花板。
4. ⚠️ sql-driver.ts 带 ADR-0120 anchor 名册，dispatch-gates.mjs 不点它 —— 需手工补跑 check:adr-anchors。
5. ⚠️ 容器与 CI 都有真 PG/MySQL（pg_ctlcluster 16 main start → 16.13；apt-get install mysql-server-8.0 → 8.0.46；CI required job Temporal Conformance (live PG + MySQL)）。⛔ 「这儿测不了」在本卡不可用 —— 三个缺陷都是实测出来的，复现它们再证明修好。
6. ⚠️ 容器前台命令 ~10 分钟被杀（exit 143）；被截断的一跑不是门禁结论。零匹配的 pnpm --filter <pkg> <script> 退出码是 0，判据取工具打印行、脚本名须回显。

---

Generated by Claude Code