Repository navigation
seedAutonumber 的播种扫描是「取前 5000 行、不排序、不按前缀过滤」的 MAX —— 超过 5000 行的对象会播种出低于真实 MAX 的号 #6249
Description
发现于 #5495 的前提复核(engine-core 车道),未在该单 PR 内顺手修,按 Prime Directive #10 单独开单。
缺陷
packages/objectql/src/engine.ts 的 seedAutonumber()(:2111 起)用一次普通 find 播种内存计数器:
const rows = await this.find(object, {
fields: ['id', field],
limit: 5000,
context: execCtx,
} as any);三个问题叠在一起:
limit: 5000是硬上限,且- 没有
sort—— 取的是驱动返回的任意 5000 行(SQL 上通常是插入顺序的前 5000 行),再在这个窗口里求 max; - 没有按
prefix下推过滤 —— 前缀筛选是在 JS 侧if (prefix && !s.startsWith(prefix)) continue;做的,所以对日期/{field}分组格式,5000 行窗口还要先被其他 scope 的行占掉。
结果:对象行数一旦超过 5000(或某个 scope 的行排在窗口之外),播种得到的 max 低于库内真实 MAX,计数器从一个已被占用的号段起号。对声明了 unique 的自增号字段,这就是直接发出撞号值。
实测(fake driver 捕获引擎实际下发的查询):
PROBE2 seedQuery={"fields":["id","case_number"],"limit":5000,"object":"crm_case"}
—— 无 sort、无 filters,limit 恒为 5000。
与 #5495 的关系
#5495 记的是另外两个缺陷(计数器不按分区同步、撞号烧号)。本条是第三个、独立的播种正确性缺陷:即使 #5495 的两条都修好,超过 5000 行的对象仍然会播种出低号。#5495 报告的 HotCRM 现场行数远小于 5000,所以本条不是那次风暴的成因,是同一函数里发现的另一个洞。
修法的难点(供分诊参考,不预设结论)
「读真正的 MAX」在引擎层没有现成的便宜写法:
sort: [{ field, direction: 'desc' }] + limit: 1取的是字符串字典序最大值。对定宽补零、且在同一前缀 scope 内的格式,字典序最大 == 数值最大;但对prefix为空的 legacy 路径(取整串最后一个数字段),字典序最大不等于数值最大。- 因此正确做法多半要按 scope 下推
startsWith(prefix)过滤 + 定宽假设,或者走aggregate的max。两条都要先决定引擎与驱动之间的契约面,不是一行改动。
影响面
只影响引擎兜底路径(驱动未声明 supports.autonumber)。driver-sql/driver-turso/driver-sqlite-wasm 走各自的 _objectstack_sequences,其播种是 scanMaxNumericTail(SQL 侧 where field like 'prefix%',无 limit),不受本条影响。
Activity
claude commentedon Aug 7, 2026
Triage:
pm:queue+domain:engine-core.Landing site.
packages/objectql/src/engine.ts,seedAutonumber()⇒domain:engine-core. Verified onorigin/main@2598216:limit: 5000is still atengine.ts:2140, in afindwith nosortand no filters — the probe in the body reproduces the query the engine actually emits.Dedup — NOT a duplicate of #5495. #5495 (
pm:queue,domain:engine-core,target:v17) records two other defects in the same area (counter not synced per partition, collision burn). This is a third, independent seeding-correctness defect in the same function: fix both of #5495's and an object past 5000 rows still seeds below the real MAX. Cross-linked both ways.Why queued rather than escalated. The body flags that the correct fix is "not a one-liner" (lexicographic max vs numeric max; pushdown of the
prefixfilter vs anaggregatemax), but those are internal engine↔driver implementation choices, not a public contract question — no authorable surface and no stored-data shape changes. That is dev design work inside a queued issue. If a dev finds the route genuinely requires a new driver capability declaration, that is the point to returnneeds_decision.Not on the release board — deliberately, with the reasoning recorded. The body establishes the blast radius is the engine fallback path only: drivers that declare
supports.autonumber(driver-sql/driver-turso/driver-sqlite-wasm) seed through_objectstack_sequencesviascanMaxNumericTail, which pusheswhere field like 'prefix%'down with no limit and is unaffected. So a shipped SQL deployment is not exposed. If someone establishes that a supported deployment shape does run the fallback with >5000 rows, that changes the answer — raise it and it goes on the board.Not affected by the driver freeze (#5499,
driver-memory/driver-mongodb): the landing site is the engine, and the drivers named above are the unaffected comparison, not the target.本评论来自分诊座位 Routine（#5474 试点），不构成认领。
Generated by Claude Code
baozhoutao commentedon Aug 7, 2026
认领(engine-core 席 #6019,会话
session_019Q7oc7ASjh8yxyS3Yz78We,第 17 轮):claude/issue-6249-seed-autonumber-window;工作树:../objectstack-6249packages/objectql/src/engine.ts(仅seedAutonumber()一带)+ 测试 + changeset。⛔ 不触同文件刚落地的 sys_file hydrate catch 位(PR fix(objectql): sys_file hydrate 读故障与「无文件」可分辨 (#6116) #6456)与其他区域。domain:drivers(真凶在 driver-sqlgetNextSequenceValue,证据在该单),该请求尚未被处理 —— 即「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 先落地」在可见窗口内不会发生,继续等它就是无限期空转。据此先行:本单预期与 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 证伪后的修法(driver-sql 侧)零文件交集;若重锚结论相反、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 需回seedAutonumber动刀,本单让位重排,以先落地者为基准 rebase。data.id(#6262) #6433 → fix(objectql,lint): 服务端为requiredWhen绑定 parent 作用域,并把构建期硬闸扩到同一格 (#4977) #6440 → fix(objectql): sys_file hydrate 读故障与「无文件」可分辨 (#6116) #6456(全部 MERGED),链上无在飞。supports.autonumber驱动不受影响,分诊已核);修法为引擎↔驱动内部实现选择,dev 设计;若路线需要新的驱动能力声明,按分诊指令停并回 needs_decision。pm:queue→pm:dispatched同步落。Generated by Claude Code
fix(objectql): seedAutonumber 播种扫描覆盖 scope 内每一行,不再取 5000 行窗口 (objects…