Turso remote:带 id/conflictKeys 但没匹配上的 upsert 仍会静默写入 NULL 自增号(#6944 拒绝闸门覆盖不到的那条腿)

[os-zhuang]

一句话说明

#6944(PR #7089)让 Turso remote 面上带 auto_number 的写入明确拒绝(NOT_IMPLEMENTED / 501),消除了"静默写 NULL"。但有一条腿没被覆盖:一个携带 id 或显式 conflictKeys 的 upsert,若实际没有匹配到任何行,就会走 insert,而自增号槽位仍然被静默写成 NULL。

由 #6944 的 dev 在实现中测得并主动申报,已在该 PR 的测试里钉成 [known residue, not fixed] 断言。本卡只负责让它在 #6944 关闭后不被埋掉。

为什么 #6944 没有一起修

拒绝闸门刻意在构建语句之前触发 —— 这正是它的价值之一:被拒绝的写入不消耗一次往返(#6944 已断言零 execute 调用)。

而"这次 upsert 到底会 merge 还是 insert",在发出语句之前无法判定:需要先去问一次数据库。要覆盖这条腿,就得引入拒绝闸门本身要避免的那次往返。这是一个真实的取舍,不是遗漏。

影响范围(承接 #6944 的实测)

remote 面上已被覆盖、会明确拒绝的路径:create、bulkCreate、以及无 id 的 upsert(其新鲜 nanoid 永远匹配不上,所以恒为 insert)、以及匹配上并合并的 upsert。

未覆盖的只有这一条:带 id / conflictKeys 且未匹配的 upsert。它的结果与 #6944 修复前一致 —— 行落地,自增号列为 NULL,调用方无从得知。

可能的处置(不预设结论)

• 接受现状:代价是 remote 面上仍存在一条静默 NULL 的窄路径,已由测试钉住,不会静默漂移。
• 付一次往返:在这条腿上先探测再决定拒绝与否 —— 与拒绝闸门"零往返"的设计取向冲突,需要权衡。
• 随 A 一起消失:若将来 appetite door 对"在 remote 上真正实现自增号"(TursoDriver remote 面根本不生成自增号:RemoteTransport.create 自建 INSERT,auto_number 只是个 TEXT 列 #6944 的处置 A)打开,这条腿自然不再存在。

关联

• TursoDriver remote 面根本不生成自增号:RemoteTransport.create 自建 INSERT,auto_number 只是个 TEXT 列 #6944 / PR fix(driver-turso): refuse auto_number writes on the remote transport (#6944) #7089 —— 拒绝闸门本体;本残留已在其测试内钉为 [known residue, not fixed]
• Autonumber counter neither syncs to MAX(existing) per tenant nor re-checks on collision — warm-DB creates 409 in bursts, each failure burning a number (25 retries observed) #5495 / bulkCreate / upsert 仍会逐次烧号:#5495 的重播种只落在 create(),批次语义是独立决策 #6943 / upsert 每次「合并到既有行」都烧一个自增号,并覆写该行已有的业务号(健康计数器上实测,与陈旧无关) #7011 —— 自增号在 SQL 家族其余面上的序列与烧号修复
• ADR-0112 / drivers(sql,turso): Unsupported aggregate function 两面都是裸 Error(code/status 皆 undefined),且三个 spec 已声明的聚合函数无任何 SQL 后端编译 #5907 —— NOT_IMPLEMENTED / 501 的二类拒绝分类

未认领,仅作记录,定级交分诊。

[os-zhuang]

Findings triage — held as finding (grading pass; routing domain:drivers already correct as filed).

• Why hold: dev-declared known residue, deliberately not fixed — covering this leg would cost the extra round-trip that TursoDriver remote 面根本不生成自增号:RemoteTransport.create 自建 INSERT,auto_number 只是个 TEXT 列 #6944's refusal gate exists to avoid (a real trade-off, recorded in place), and the current outcome is pinned in PR fix(driver-turso): refuse auto_number writes on the remote transport (#6944) #7089's tests as known residue, so it cannot drift silently. Narrow path (upsert carrying id/conflictKeys that matches nothing), no reported caller hitting it.
• Restart conditions: (a) the appetite door opens on actually implementing autonumber on Turso remote (TursoDriver remote 面根本不生成自增号:RemoteTransport.create 自建 INSERT,auto_number 只是个 TEXT 列 #6944 disposition A) — this leg then disappears and the card closes with it; (b) a first real report of a caller landing on the silent-NULL leg — re-grade for promotion; (c) any rework of the upsert-merge path in the Autonumber counter neither syncs to MAX(existing) per tenant nor re-checks on collision — warm-DB creates 409 in bursts, each failure burning a number (25 retries observed) #5495/bulkCreate / upsert 仍会逐次烧号:#5495 的重播种只落在 create(),批次语义是独立决策 #6943/upsert 每次「合并到既有行」都烧一个自增号,并覆写该行已有的业务号(健康计数器上实测,与陈旧无关) #7011 family that touches this leg — re-verify the pin still holds.
• Premise note: the pin lives in PR fix(driver-turso): refuse auto_number writes on the remote transport (#6944) #7089's test suite (in flight at filing time), so it was not re-verified against origin/main; the hold does not depend on it having merged.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[os-zhuang]

Drivers seat — premise verification only. Not a claim, no label changed, grade untouched.

Triage's 2026-08-09 hold carried an explicit caveat: the pin "lives in PR #7089's test suite (in flight at filing time), so it was not re-verified against origin/main". #7089 has since merged, so that is now checkable, and I checked it.

The pin landed and it is live — packages/drivers/driver-turso/src/turso-remote-autonumber-refusal.test.ts:311:

it('[known residue, not fixed] an id-bearing upsert that INSERTS still writes NULL', async () => {
 …
 const inserted = await driver.upsert('crm_case', { id: 'never-seen', organization_id: 'orgA', title: 'inserted by upsert' });
 expect(inserted.case_number).toBeNull();
});

Not skipped, not a comment, not vacuous — a real assertion, and deliberately bidirectional: its own docstring says it is "stated as an assertion rather than a comment so it cannot quietly become untrue in either direction." If anyone closes this leg, that test goes red and forces the conversation rather than letting the change land unremarked. Triage's stated reason for holding — "pinned, so it cannot drift silently" — is therefore sound on measured ground, not on an assumption.

Status of the three restart conditions, as measured today:

• (a) appetite door on TursoDriver remote 面根本不生成自增号:RemoteTransport.create 自建 INSERT,auto_number 只是个 TEXT 列 #6944 disposition A — not opened. Unchanged.
• (b) a first real report of a caller hitting the silent-NULL leg — none found.
• (c) rework of the upsert-merge path in the Autonumber counter neither syncs to MAX(existing) per tenant nor re-checks on collision — warm-DB creates 409 in bursts, each failure burning a number (25 retries observed) #5495/bulkCreate / upsert 仍会逐次烧号:#5495 的重播种只落在 create(),批次语义是独立决策 #6943/upsert 每次「合并到既有行」都烧一个自增号,并覆写该行已有的业务号(健康计数器上实测,与陈旧无关) #7011 family touching this leg — none; the pin above still holds.

Why this seat is not dispatching it, despite the mandate to. The maintainer's 2026-08-10 direction (「drivers 任务全部可派,v17 只是优先」) removed triage hold grades as a dispatch blocker, and this seat has acted on that — #6522 ran under exactly that authorization. But it does not convert this card into execution work. Its own body declines to presuppose a conclusion, and its three options are an appetite trade-off rather than three ways to write the same fix:

• accept the status quo — no code changes at all;
• pay a round trip — buys the leg at the direct cost of the zero-round-trip property TursoDriver remote 面根本不生成自增号:RemoteTransport.create 自建 INSERT,auto_number 只是个 TEXT 列 #6944's refusal gate was built to have (fix(driver-turso): refuse auto_number writes on the remote transport (#6944) #7089 asserts zero execute calls on a refusal);
• wait for disposition A — and the leg disappears on its own, taking the card with it.

Dispatching would mean this seat picking one, which is the maintainer's call, not a PM's and not a dev's. So it stays held — now on a verified premise instead of an unverified one — and what it actually needs is a ruling on #6944's disposition A, not a developer.

---

Generated by Claude Code

[claude]

Findings triage (re-verify @ origin/main c6a4eeb): HOLD — the uncovered leg is still pinned as [known residue, not fixed] (turso-remote-autonumber-refusal.test.ts:311). The three-way disposition (accept / pay a round-trip / dies with remote autonumber option A) is a genuine tradeoff tied to the appetite door, so this stays held rather than queued. finding stands.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[claude]

Findings triage (re-verify @ origin/main afdc6ea): HOLD — the uncovered leg is still pinned as known residue at packages/drivers/driver-turso/src/turso-remote-autonumber-refusal.test.ts:311 (the case titled "[known residue, not fixed] an id-bearing upsert that INSERTS still writes NULL"). The three-way disposition (accept / pay a round-trip / dies with remote-autonumber option A) is a genuine tradeoff tied to the appetite door, so it stays held rather than queued. finding stands.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[claude]

Maintainer ruling — 2026-08-11. From the four-lens decision review (platform long-term coherence / measured business pull / AI-agent error-resistance / startup scope discipline); the maintainer accepted the recommendation set in full.

Ruling: hold confirmed — the residue-pin tradeoff stays tied to the appetite door; the restart condition already recorded on this card stands. finding stays.

Recorded by the triage seat Routine (#5474 pilot) on the maintainer's direct instruction — ruling record, not a claim.

---

Generated by Claude Code

[os-zhuang]

Findings triage round, 2026-08-11 (maintainer-directed). Graded: hold — the residual leg is pinned in tests as known residue and covering it costs the round-trip the refusal gate exists to avoid; a real trade-off, honestly recorded. Restart: a user report of the unmatched-upsert leg, or the next Turso driver batch (re-weigh the probe cost there).

---

Generated by Claude Code

[os-zhuang]

Read-only factual correction on the hold's cost premise. ⛔ Not a claim, no label changed, no re-grade — the disposition is triage's and the maintainer's. All facts verified on origin/main @ c41828d before writing.

The recorded restart condition includes "the next Turso driver batch (re-weigh the probe cost there)". A Turso batch just landed (#8198, merged a5dcb74), it touched this exact class, and the re-weigh comes out differently than the hold assumed.

① The round trip the refusal "exists to avoid" is already being paid, unconditionally

The pinned residue case states the premise as settled fact (turso-remote-autonumber-refusal.test.ts:311):

RemoteTransport.upsert emits INSERT … ON CONFLICT DO UPDATE, and whether that statement merges or inserts is knowable only after it runs — a round trip this refusal exists to avoid.

But RemoteTransport.upsert (remote-transport.ts:1210) already performs that round trip on every call:

await this.client!.execute({ sql, args: values }); // the INSERT … ON CONFLICT
const result = await this.client!.execute({ // ← already paid, every time
 sql: `SELECT * FROM "${object}" WHERE "id" = ?`,
 args: [toUpsert.id],
});
const rows = this.mapRows(result);
return rows[0] || toUpsert;

The pin's own assertion reads that round trip's result — expect(inserted.case_number).toBeNull() is reading the row this SELECT returned. The NULL is already in hand at zero additional cost.

And the detection is simpler than the premise frames it: this leg does not require distinguishing merged from inserted. It requires noticing that an autonumber column came back NULL, which is one field read on a row the method already has.

② A diagnostic sink now exists in this class, and did not when the hold was written

#8198 gave RemoteTransport a one-way sink — private diagnosticSink (remote-transport.ts:853), registered via setDiagnosticSink(), wired by TursoDriver at construction as setDiagnosticSink((message) => this.logger.warn(message)) (turso-driver.ts:373). So the "silently" half of this card's title is now separable from the refuse-or-generate half: warning an operator costs a log line, not a round trip.

What this does NOT establish

• ⛔ It does not say the leg should be refused. Refusing after the write already happened is a different act from refusing before it, and that trade-off is untouched by the above.
• RemoteTransport has no autonumber or schema awareness — grep for autonumber/autoNumber in that file returns nothing, so it cannot today tell which column is an autonumber. Closing this leg needs the driver to hand that rule down. That is plumbing with two established precedents in the same class (setFilterColumnSql, setDiagnosticSink), not a round trip — but it is real work, and I have not measured it.
• The deferred-half (A) relationship to remote autonumber generation is unchanged.

Net: the disposition may well stay held — but if it does, it should rest on a premise that is true. The stated one is not.

---

Generated by Claude Code