Repository navigation
Flow 设计器给每个新建 wait 节点种下 spec 17 已退役的 waitEventConfig.onTimeout，发布即 422 #3316
Description
发现于 framework #4001 批 11（automation/flow.zod.ts 的六个内层块收紧）的跨仓核验，不在该批范围内，未修。这条不是批 11 造成的 —— 它今天就已经会失败。
事实
packages/app-shell/src/views/metadata-admin/previews/flow-canvas-parts.tsx:385，defaultNodeExtras() —— 新建节点的种子字段：
case 'wait':
return { waitEventConfig: { eventType: 'timer', onTimeout: 'fail' } };FlowCanvas.tsx:52 导入并使用它，所以在设计器里拖出来的每一个 wait 节点都带着 onTimeout。另一处 FlowCanvas.tsx:367（approval 送回修改时自动插入的 wait 节点）同样写死了 onTimeout: 'fail'。
onTimeout 在 @objectstack/spec 17 被 #4158 退役，实现方式是 retiredKey() —— 即 z.never().optional()。它不是被静默剥离，是 FlowNodeSchema.parse() 的硬错误，并且带着处方：
waitEventConfig.onTimeoutwas removed in @objectstack/spec 17 (#4158). It had no readers at all — no code path ever inspected it, so neitherfailnorcontinueever happened. Delete the key.
即：设计器保存/发布一个 wait 节点时，spec 17 的 FlowSchema.parse 会拒绝设计器自己生成的形状。
为什么值得单独记一笔
同一次退役的另一半，objectui 已经跟上了：views/metadata-admin/i18n.ts:3519 就地写着
// `waitEventConfig.timeoutMs` / `.onTimeout` 的覆盖随字段一并移除(#3101)
标签覆盖删了，产出这个键的默认块没删。一次退役、两个消费点、只改了看得见的那个 —— 和 framework #4001 反复记录的「bespoke 守卫只守一扇门」是同一形状，只是这次分岔在同一个仓的两个文件之间。
建议
defaultNodeExtras('wait')→{ waitEventConfig: { eventType: 'timer' } }（timerDuration由作者填；它接受裸数字作为毫秒，正是timeoutMs的替代路径）。FlowCanvas.tsx:367的 revision-wait 节点同样去掉onTimeout。- 顺带值得核一遍：
defaultNodeExtras里其余分支（connector_action/boundary_event/approval/notify）的键都在批 11 收紧后逐一比对过，均已声明，无第二例。
相关
- framework [gantt] Illegal dependency link (cycle/self/locked/group) is silently discarded — no toast, no cursor, no reason shown #4158（
waitEventConfig.timeoutMs/.onTimeout退役） - framework examples/schema-catalog: 13 个 grid 示例用了未声明的
cols键,列数被静默丢弃 —— 要 3/4 列的示例在 docs 站实际渲染成 2 列 #4001 批 11（waitEventConfig等六个内层块转 strict —— 本条是核验副产物，非其后果） - objectui
wait表单仍提供已退役的waitEventConfig.timeoutMs/.onTimeout—— 下一次 spec rc 刷新会被对账测试点名 #3101（同一退役的 i18n 侧清理）
Activity
yinlianghui commentedon Aug 5, 2026
认领:objectui 分片 PM 循环第 1 轮(v17 A 组,GA 前硬阻塞)
会话:
session_01GTRjn8xBqp75dk7kFupVRt分支:
claude/issue-3316-flow-wait-ontimeout-seedWorktree:
objectui-issue-3316域:objectui 分片(app-shell / metadata-admin previews)
文件面:
packages/app-shell/src/views/metadata-admin/previews/flow-canvas-parts.tsx、packages/app-shell/src/views/metadata-admin/previews/FlowCanvas.tsx+ 同目录测试 +.changeset/*.md(越界即停,报告说明)前提已对⚠️ 同日 churn 注记:#3294(flow 节点几何收敛,6e794a1)在本单立单后动过同批 flow 文件,
origin/main@68b6a28核验:两处onTimeout种子仍在(flow-canvas-parts.tsx:385、FlowCanvas.tsx:367)。FlowCanvas.tsx:367现为eventType: 'signal', signalName: 'revision', onTimeout: 'fail',与正文引用的快照已有出入 —— 派发词已要求 dev 以当前 origin/main 为准。Generated by Claude Code
yinlianghui commentedon Aug 5, 2026
PM 验收:ACCEPT → PR #3371 已转 ready + auto-merge(报告时 4 个 test 分片在跑,其余 11 项全绿;绿齐自动入队),跟到 MERGED。
落地内容:两个生产者(
defaultNodeExtras('wait')与addReviseLoop的 revision-wait)都不再种onTimeout;新增flow-canvas-seeds.spec-parse.test.tsx(25 例)按生产者而非文件划覆盖面 —— NODE_PALETTE 全类型 + start/end/http_request/boundary_event 整节点过 specFlowNodeSchema,revision-loop 节点从真实按钮点击捕获;config根的残缺种子(approval/notify/http)下沉到键级对 spec 在生键判定,并带[REMOVED]墓碑点名断言 —— 下一次退役会直接红在种子处并报出是哪个键。反向验证 4 红逐条点名,与预判方向一致。附加价值:① issue 建议第 3 点核验完成,其余分支无第二例;② 修正 issue 旁注 —— rc.2 下
timerDuration是z.string(),裸数字被拒,字符串通过(已记录防后人踩空);③ 消费半径扫描确认无陈旧 fixture 仍拼写onTimeout。v17 A 组(GA 前硬阻塞)至此代码侧闭环,待队列落地。
objectui 分片 PM
session_01GTRjn8xBqp75dk7kFupVRtGenerated by Claude Code
fix(app-shell): drop the retired waitEventConfig.onTimeout from flow …