[Bug] The job list Clear control cannot dismiss a finished job

[chan58]

Component: packages/api/job-controller (shipped as @deepseek-ai/dsh-api-job-controller)

Symptom

A finished background job cannot be removed from the job list. The Clear control above the list does not clear it - the click appears to do nothing, and the entry persists for the session.

It is mildly annoying rather than blocking, but it makes the list mislead: a finished row reads as activity.

Reproduction

Let any background job finish - a long build or plan is easiest - then use Clear above the job list. The finished job remains.

Mechanism, read from the shipped source

• lib/types/observe.js does handle removal: it "closes it with the removed job's terminal projection" and speaks of having "dropped the record". So the roster can emit removed, and the client mirrors it.
• lib/types/index.js exposes exactly one mutating request: _kill_decorators = [Remote('kill')] - "Kill one background job on a human's behalf" - documented as returning "the registry's admission of the kill request", so it can be refused.
• It is refused for a terminal job. Observed through the tool API: job bash-337 had already finished [status: completed, exit code: 0].

So no available path lets the client dismiss a job that has already finished.

Suggested fix

Add a dismiss / remove Remote that accepts a terminal job. The removed projection path already exists, so only the request is missing. More cheaply: let kill on an already-finished job drop it from the roster and return an admission the client can act on.

Worth separating

The retention is not the bug. Keeping a finished job's output is the right behaviour, and README.md line 1 describes the roster as "the roster one session can see". The defect is that nothing can dismiss it.

Caveat on my evidence

I could not read the UI's Clear handler - the client is a bundled asset and no file is named for it - so identifying Clear with kill is inference from the API surface, not something I read. The underlying gap, that no dismissal request exists, is read directly from the source.

[PerryLink]

你的现象描述和方向判断都对，我核完最新线（origin/master = 571902028a，2026-10-14）后可以给你一个明确的答案：remove() 早就实现了，缺的只是一个远端入口，大约 10 行。但你有一处推断是错的，那处错了会让诉求指向错误的地方。

1. ⚠️ 先更正一处：「Clear 大概是调 kill」不成立

packages/client/ui-jobs/src/client/JobListAction.tsx：

• :348 → const [clearedKeys, setClearedKeys] = useState<ReadonlySet<string>>(() => new Set())
• :456 → const clearSettled = (): void => {
• :457-460 →

setClearedKeys((current) => {
  const next = new Set(current)
  for (const job of settledRows) next.add(String(job.id))
  return next
})

• 该处注释（旧基线 :345-347，现 :346-348）写着：Rows the user cleared from the settled tail (client-side hide only; the registry keeps its records…)

⇒ Clear 只往一个本地 Set 塞 id，不发任何远端请求、也不调 kill。 它"不生效"的原因不是后端拒绝，而是：

1. 粒度：按钮挂在 settled 区块的表头（:562 附近，条件 settledRows.length > 0），所以它只能整段清"已结束"区块；
2. 折叠：该区块默认展开与否由 settledExpanded = settledOpen ?? liveRows.length === 0 决定（:360 附近），所以你"清了但看起来还在"的情形很可能是折叠态造成的观感。

⇒ 把"Clear 大概调 kill"从报告里删掉，否则维护者会先纠正这一点，而你的真诉求会被埋在下面。

2. ✅ 你说对的部分：没有 dismiss 这个远端入口

packages/api/job-controller/src/index.ts（这个文件在最近 868 个提交内一字未改）：

• :75 → @Remote({ mode: 'stream' })（list）
• :90 → @Remote({ mode: 'stream' })（follow）
• :109 → @Remote('kill')

⇒ 只有 list / follow / kill，没有 dismiss / remove。 全文件里 dismiss|remove 仅 1 处命中且是注释（:122）。

3. ⭐ 关键：Service 侧的 remove() 早就存在，而且语义正好是你要的

• packages/jobs/jobs/src/index.ts:179 → * Drop one settled job's record from the visible set and announce … :186 → abstract remove(id: JobId, caller?: SessionId): void
• packages/jobs/jobs-local/src/index.ts:340 → remove(id: JobId, caller?: SessionId): void {；:342 → if (!isTerminal(job.status)) throw new Error(...)；:343 → this.drop([job])

⇒ 它只接受终态 job（非终态会明确要求你先 kill 并等结算）—— 这正是"dismiss 一个已结束的 job"的语义。

而 kill 对终态是死路：jobs-local/src/index.ts:484-485 → private killJob(...) / if (isTerminal(job.status)) return 'already-finished' ⇒ 已结束的 job 再 kill 不会 drop 它。

4. ⭐ 最有力的一条：jobs.remove() 没有任何生产调用方

git grep "jobs\.remove(" → 只命中 packages/jobs/jobs-local/tests/jobs.spec.ts（测试专用）。

⇒ 也就是说：这个能力已经写好、被测过，但从未被接到任何产品路径上。 这是这条报告最该强调的形态 —— 它不是"缺功能"，而是"功能已实现但未接线"。这个说法比"希望能清除"强得多，因为它把工作量讲清楚了。

5. 建议的诉求（可直接照用）

JobsService.remove(id, caller?) 已实现（jobs/src/index.ts:186、jobs-local/src/index.ts:340-344），语义正确（只接受终态，非终态明确拒绝）；但它没有任何生产调用方（git grep "jobs\.remove(" 仅命中测试）。同时 api/job-controller/src/index.ts 只暴露 list/follow/kill，kill 对终态返回 already-finished 而不 drop。⇒ 请在 job-controller 增加一个 @Remote('dismiss')（照 kill 的三段式：jobs.get → 未命中抛 RemoteError('job/not-found') → jobs.remove(...)），并把 JobListAction 的 clearedKeys 本地隐藏改为真调用。

6. 一处需要你自己确认的（我无法替你判）

你的诉求里说"Clear 无法消除一个已结束的 job"——请区分两种情形，它们的修法不同：

1. 点 Clear 后该 job 仍在列表里 ⇒ 那是第 1 节的粒度/折叠问题（UI 侧）；
2. 列表里根本没有针对单个 job 的清除入口 ⇒ 那才是第 5 节的 dismiss 缺口（API 侧）。

⚠️ 我没有运行界面，所以哪一种是你的实际情形需要你确认。建议在报告里把这两者分开写 —— 现在的写法把它们混在一起了。

7. 版本与行号

• 我核的是 origin/master = 571902028a（2026-10-14）。⚠️ 与你原报告的行号相比有几处漂移，请更新：jobs/src/index.ts 175-183 → 178-186；jobs-local/src/index.ts 336-340 → 340-344、458-459 → 484-485；JobListAction.tsx 455-464 → 456-465。
• ✅ 而 job-controller/src/index.ts 的 :75/:90/:109 零漂移（该文件未改），可以直接用。
• ⚠️ 另注意：dsh-v0.2.1-alpha.3（2026-10-14 发布）= 2fbf4359b8，与 master 不是同一个提交（master 比它多 16 个提交）。上表行号是 master 的；请在你自己的产物里对一遍。