drivers(turso): 聚合函数名的大小写归一化 local/remote 不一致 —— `COUNT` 在 remote 编得出、在 local 被拒(同一个 TursoDriver,取决于 url)

[os-zhuang]

从 #5907(聚合函数拒收信封,两面同改)的落点实测中带出。不在该单的信封面内(该单只改拒收的 code/status 与措辞,不动「什么能编译」),按 Prime Directive #10 单独记一笔。

观察类:仓内没有活体发送方,协议门也表达不出这个输入 —— 严重度请分诊时判定。

事实

两个面对聚合函数名的归一化不一样:

• packages/drivers/driver-turso/src/remote-transport.ts — aggregate() 先 .toLowerCase() 再查自己的编译表;
• packages/drivers/driver-sql/src/sql-driver.ts — mapAggregateFunc() 拿到什么查什么,不归一化。

TursoDriver 按 url 选面(本地/副本继承 SqlDriver,远程委派 RemoteTransport),于是同一个驱动、同一条查询,答案取决于连接串。在 origin/main @ 80f7dc6a3 实测(一条 aggregations: [{ function, field: 'stage', alias: 'n' }]):

COUNT           REMOTE -> RESOLVED  "SELECT count(\"stage\") AS \"n\" FROM \"deal\""
COUNT           LOCAL  -> THREW     "Unsupported aggregate function: COUNT"

COUNT_DISTINCT  REMOTE -> THREW     "Unsupported aggregate function: count_distinct"   (注意:回显的是归一化后的名字)
COUNT_DISTINCT  LOCAL  -> THREW     "Unsupported aggregate function: COUNT_DISTINCT"

Median          REMOTE -> THREW     "Unsupported aggregate function: median"
Median          LOCAL  -> THREW     "Unsupported aggregate function: Median"

第一行是分叉本身:一个面返回行,另一个面抛错。后两行是同一归一化的影子 —— 拒收消息回显的名字不是调用方写的那个。

为什么记一笔

• 这正是 drivers(turso): RemoteTransport 条件层的 $-算子键被当列名编译成静默空集 —— SqlDriver 已按 #5348 拒收,remote 是唯一剩余面(cloud#1077 移交) #5769 花整单去关的那类叉(一个条件、两种线上身份、取决于 url),只是落在聚合层的编译能力上而不是拒收信封上。
• AggregationFunction 是大小写敏感的 z.enum,AggregationNodeSchema.function 因此表达不出 COUNT。所以 remote 今天接受的是一个协议从未声明的拼写 —— PD#12 的宽容消费方形状:声明侧只有小写,消费侧偷偷多认一种方言。

为什么今天没人撞上(=> 观察类)

• 全仓搜 function: 'COUNT' / 'SUM' / 'AVG' / 'MIN' / 'MAX'(大写)零命中,没有活体发送方;
• 经 REST/协议门进来的查询过 AggregationNodeSchema,大写拼写在到达任何驱动之前就被拒;
• 只有绕过 spec 校验的进程内调用方才够得着。

修法(供分诊,两个方向相反)

1. 收紧 remote(契约优先,倾向这个):删掉 .toLowerCase(),两面都只认协议声明的小写拼写,COUNT 在两面都落 drivers(sql,turso): Unsupported aggregate function 两面都是裸 Error(code/status 皆 undefined),且三个 spec 已声明的聚合函数无任何 SQL 后端编译 #5907 的第 1 类拒收(INVALID_QUERY / 400,「不是已声明的聚合函数」)。与本仓两次同形先例一致(RemoteTransport.findOne 的未声明 string-id 分支、FilterArray 的第二套编译器,都是删掉后收敛到一种拼写)。代价:任何今天靠大写拼写工作的进程外调用方会开始拿到 400 —— 但那本来就不是协议表达得出的输入。
2. 放宽 local:给 mapAggregateFunc 也加 .toLowerCase()。两面同样收敛,但方向是把方言固化成第二套事实上的契约,PD#12 明确反对。

已经钉住的部分

#5907 的 PR 在 remote-transport-aggregate-function-refusal.test.ts 里留了一条如实记录现状的用例([filed, not fixed] COUNT still compiles HERE while the local driver refuses it),这样下一个读者是读到它、而不是重新踩一遍;同一 PR 也把两面的拒收分类改为按调用方写的原始拼写判定,免得归一化差异顺着信封扩散(否则 COUNT_DISTINCT 会在 remote 拿 501、在 local 拿 400)。所以本单剩下的只有「什么能编译」这一半。

相关:#5907(带出本单)、#5769(同族 local/remote 叉)、#6188(那三个已声明未实现的函数按 ADR-0049 的去留)。

[os-zhuang]

车道裁决(第三档,带否决窗口)+ 认领

裁定:方向 1 —— 收紧 remote,删掉 .toLowerCase(),两面只认协议声明的小写拼写;COUNT 在两面统一落 #5907 已落地的第 1 类拒收(INVALID_QUERY / 400,「不是已声明的聚合函数」)。

这不是新裁决,是三条既有规矩的应用,故不占维护者决策位(可否决):

• AggregationFunction 是大小写敏感的 z.enum,COUNT 是协议从未声明的拼写——remote 今天多认的是一种方言,PD#12 明确反对在消费端偷偷放宽;
• 仓内两处同形先例都是删掉宽容侧收敛到一种拼写(RemoteTransport.findOne 的未声明 string-id 分支、FilterArray 的第二套编译器);
• 方向 2(给 local 也加 .toLowerCase())会把方言固化成第二套事实上的契约,与上一条相反。

风险已由本单自证可接受:全仓大写拼写零活体发送方,经协议门的查询在到达驱动前就被 AggregationNodeSchema 拒,只有绕过 spec 校验的进程内调用方够得着。

---

认领:PM 循环第 11 轮续批(drivers 车道)
会话:session_01WyvqvKMG6asi9aXjKE6xtx
分支:claude/issue-6203-aggregate-case-normalization
Worktree:objectstack-issue-6203
文件面:driver-turso/src/remote-transport.ts(aggregate 归一化处)+ remote-transport-aggregate-function-refusal.test.ts(把 #5907 留的 [filed, not fixed] 现状用例翻面)+ changeset
前置已清:#6204(#5907 信封)与 #6210(#6075 签名)均已 MERGED。并行:#5234 在飞(driver-sql applyLike 区 + service-analytics),零重叠。

---

Generated by Claude Code

[os-zhuang]

复核:ACCEPT → PR #6312(PM 实测复核):

• 变更面 4 文件与申报一致;RemoteTransport.aggregate 的 .toLowerCase() 已删净;driver-sql 侧实测为纯注释(订正那句「remote lowercases it」的现状描述——本 PR 之后不再成立,是必要的防假话);冻结面零改动;
• 裁决执行到位且未越界:确认「不需要新增分类逻辑」——fix(drivers): 聚合函数拒收带上 ADR-0112 信封,并把两类条件分开措辞 (#5907) #6204 已按调用方原始拼写分类,删归一化后 COUNT 自然落第 1 类 400,措辞与 local 逐字相同;信封/降级表/签名/条件层闸一律未触;
• 反向验证的分向预判是这单的亮点:预判四条不同向(COUNT/Count 应红且红在「but it compiled」,COUNT_DISTINCT/Median 应绿不动,因为归一化后仍查不到表、而 drivers(sql,turso): Unsupported aggregate function 两面都是裸 Error(code/status 皆 undefined),且三个 spec 已声明的聚合函数无任何 SQL 后端编译 #5907 早已按原始拼写分类),实测 2 failed | 806 passed 与预判逐条吻合。并保留了那两条不敏感用例——理由正确:它们守的是「归一化若从分类侧回来」的另一条路径,只有它们看得见;
• 控制用例补得对:小写 count 在两面依然照常编译,防「靠全拒收也能满足 parity」;aliasless 用例去掉已不可表达的 miscased 维、保留它真正钉的那一维;
• 每条断言 code + status([skill] 拒收类用例必须断言 code+status,不能只断言「它抛了」—— 否则在裸 Error 的驱动上恒绿(#6142 实测) #6144);消费半径用前缀 filter([skill] 消费半径扫描必须用 --filter '...pkg'(前缀)而非 'pkg...'(后缀)—— 方向扫反会让「全绿」毫无意义(#6210 实测) #6218);erasure 棘轮 267 未抬、type-check-debt 34 条无超记录;
• 影响面自证:全仓大写拼写零活体发送方、协议门在驱动之前就拒,受影响的只有绕过 spec 校验的进程内调用方——changeset 升级说明已写明作者侧修法。

已转 ready + auto-merge,CI 绿即入队。

---

Generated by Claude Code