[jobs] job_output(wait:true) 有新输出也不返回,只在任务结束或超时时唤醒:流式任务每次都睡满 timeout(0.1.5-rc.2 实测)

[TT-Wang]

在 0.1.5-rc.2(master c291e7961a)上确认:job_output 的 wait: true 只在任务结束或超时到期时返回,不认「有新输出」。对一个持续产出的后台任务,等待开始后不到一秒就有了新行,工具也要睡满超时才返回。

先说清楚这不算违背文档:wait 的参数描述原文就是 "Block until the job reaches a terminal status or the timeout expires."。问题在于这个契约对流式任务不合适,而 30 秒的默认值、600 秒的上限、以及系统提示词里 "set wait: true only when you are genuinely blocked on it" 的邀请,让模型读进度时一次次白白占住回合。

实测

0.1.5-alpha.1 源码构建(其 packages/jobs/*/src 与 rc.2 逐字节相同),隔离的 DSH_HOME。计时取自会话日志里 tool/call 与 tool/result 事件的宿主时间戳。

后台每秒打印一行带毫秒戳的 tick,随后 job_output {wait: true, timeout_ms: 6000}:

项	值
wait 开始后第一行新输出出现	+0.44 s
工具实际返回	+6.03 s
带回的行	tick 1–7,其中 6 行产生于 wait 开始之后
紧接着的无 wait 读取	0.01 s,立即拿到新行

后台 sleep 45,job_output {wait: true} 不传 timeout_ms:阻塞 30.01 秒,返回 (no new output) + [status: running]。

输出在 0.44 秒时就已可读,wait 却睡满 6 秒;无 wait 读取随时能拿到增量;任务结束本来就会自动推送完成通知。对「看进度」和「等结束」这两种最常见的意图,阻塞式 wait 什么都没多给。

代码路径(行号为 0.1.5-rc.2)

packages/jobs/jobs-local/src/index.ts:230-279 的 wait 只有两个唤醒源:settle() 释放 waitResolvers(:424-426),以及 deadline() 定时器(:250,超时走 :263-265 的 resolve())。没有「有新输出」的路径。

packages/jobs/tool-jobs/src/index.ts:48-49 的默认值是 30s / 600s,:332-333 用 Math.min(args.timeout_ms ?? waitDefault, waitCap) 截断。全仓没有任何挂载覆盖这两个值。工具描述只写 "waits up to the configured cap"(:303-305),不给数字;工具刻意不声明 timeoutMs(:306-307),所以 tool-call-timeout 策略也兜不住。

叠加因素:执行期没有中间事件,UI 整个等待期只有一张挂起卡片;busyEnter 默认 queue(packages/client/ui-conversation/src/submission-settings.ts:18),等待期间发的消息只会排队。

git diff dsh-v0.1.5-alpha.1 c291e7961a -- packages/jobs/ 只动了 README 与 package.json,src 未变。

与相邻讨论的关系

我们前两天报的 #6030(steer 无法抢占阻塞中的 wait)是同一个函数缺了另一个出口:那边缺「有排队输入就醒」,这边缺「有新输出就醒」。#1542(job 挂死时 wait 超时只回 [status: running]、没有活性信号)相关但不同,那是分不清慢和卡死,这是明明有输出却不返回。

想讨论的修法

P1a(只改 tool-jobs,约 40 行):wait: true 时让 ctx.jobs.wait 与一个 100–250ms 的轮询赛跑,轮询调用 ctx.jobs.read 累积增量,非空即返回。对 final-output 任务安全,因为没有 readOutput 时运行中的 read() 返回空串(jobs-local:208-210)。

P1b(正规做法):registry 加非消费的 peek 与生产方的「输出已追加」通知,wait 增加 until: 'settle' | 'output' | 'either'。

P2(零代码):挂载行加 waitTimeoutMs: 5000、maxWaitTimeoutMs: 60000,单次最坏静默从 10 分钟降到 1 分钟。

另外三条成本递增:描述里写出真实上限并说明完成会自动通知(P3);为长工具调用加 tool/progress 一类的进度事件(P4);工具阻塞期间把 busyEnter 默认改为 steer(P5)。

验收可以这么定:追加输出但未结束时,等待中的读取在 250ms 内带新文本返回,任务仍 running 且未标 reported;静默任务照旧按超时返回;中止仍以 wait aborted 拒绝且 resolver 计数归零;现有 jobs.spec.ts:450-500 与 tool-jobs.spec.ts:164-199 原样通过。

想问维护者:P1a 和 P1b 你们倾向哪个?如果走 P1b,until 能不能同时覆盖 input-pending,把 #6030 一起收掉——两个缺陷改的是同一处。

[argszero]

这个缺口已经做成了插件形态的方案（社区侧，不需要上游改动）：

@argszero/cordis-plugin-steer-preempt v0.2.0 — https://www.npmjs.com/package/@argszero/cordis-plugin-steer-preempt
源码：https://github.com/argszero/cordis-plugin-steer-preempt

- insert:
    - id: steer-preempt
      name: '@argszero/cordis-plugin-steer-preempt'

挂上即可，无需配置。它包 tools/execute（与树内 guard/timeout-policy 同一个缝），只拦 job_output(wait: true)：一旦观察到目标作业有新输出，就 abort 衍生 signal 让这次 wait 提前返回，作业本身继续跑、不杀。默认 deliver: 'wrap' 返回结构化 JOB_OUTPUT_RESUMED 结果，带上观察到的增量 + [status: running]，明确不是超时也不是完成；deliver: 'cut' 保留工具自己的早返回；deliver: 'off' 关闭该触发（只剩原有的 steer 抢占）。作业在 grace 窗口内结束仍走真实结果。

实现时有一条契约事实值得记在这里，因为它决定了这件事只能怎么做：

jobs.read 的输出光标是单向的——只返回「上次 read 之后新产生的」并把光标推过去；onJobsChanged 只在可见集合变化时触发（注册 / stopping / settled / 移除），append 不触发。所以不存在非消耗的手段去问他有没有新输出：观察本身就是那次消耗。因此插件把观察用的那次 read 的结果直接交给模型，而不是丢掉——为了继续等而丢掉的增量就是它的唯一副本。空 read 不触发，所以静默作业、final-output 作业不会被误判成「有新输出」；没观察到就没读过，工具自己的 read 保持原样。

wait: true 的语义没有被改写：不新增错误码、不改 timeout_ms 的处理、不覆盖 provider 的 finish 原因，只是把一次等待缩短。

需要说明的是这仍是社区侧止血：真正意义上的「有输出即唤醒」属于 jobs-local / tool-jobs 的唤醒源设计（例如让 wait 同时等一个输出事件），那属于 core 面的 upstream-fix，插件只能绕到缝上。