[dsh-llm-deepseek] A completed response with no visible content passes as a legal stop — the empty-response guard can never fire

[yamingmou]

Summary. @deepseek-ai/dsh-llm-deepseek@0.1.5-rc.2 has an empty-response guard that is meant to turn a completed response carrying no content into a retryable EMPTY_RESPONSE error. Its predicate tests whether any block was opened, not whether anything visible was produced — and a streamed reasoning token opens a reasoning block. So a turn that streams only reasoning always satisfies the guard's negative case and is reported as a normal completion. The response is not retried, and the user sees a turn that "finished" with nothing on screen.

Where.

// dsh-llm-deepseek/lib/index.js
:1213  const order = [];
:1216  function open(kind) {
:1222    order.push(block)                       //  ← every opened block lands here
:1236  const reason = pendingFinish ?? { kind: "stop" };
:1239  reason: reason.kind === "stop" && order.length === 0
:1240    ? { kind: "error", failure: { message: "model returned a completed response with no content",
:1243                                 code: EMPTY_RESPONSE_CODE } }
:1245    : reason
:1257  if (typeof reasoning === "string" && reasoning.length > 0) {
:1258    if (!reasoningBlock) { reasoningBlock = open("reasoning"); … }   //  ← opens a block

A reasoning-only turn opens exactly one block, so order.length === 0 is false and the guard falls through to { kind: "stop" }.

What the release says the guard is for — in its own words. The rationale ships next to the constant:

// packages/llm/llm/src/error.ts:28-37
 * Canonical provider-neutral code for a response that completed normally but
 * carried no content blocks at all. Providers occasionally emit a degenerate
 * completion (a terminal stop with zero output); adapters classify it as this
 * failure instead of yielding an empty assistant message, because an empty
 * message silently ends the turn with nothing for the user or the loop to act
 * on. The attempt produced nothing durable, so retry policy treats it as safe
 * to repeat.

That rationale is stated as an effect: a turn that ends with nothing for the user or the loop to act on. A reasoning-only turn has exactly that effect. The predicate, though, is faithful to the phrase it was written from — "carried no content blocks at all" — and a reasoning block is a content block. So I am not claiming the guard ignores its own intent. I am claiming that on this shape the stated rationale and the predicate's phrasing part company, and that the phrasing is what reached the code. Two supporting facts, both from the same release:

1. EMPTY_RESPONSE_CODE is the first entry of the default retryable set — dsh-llm/lib/index.js:236-242 (DEFAULT_MAX_RETRIES = 5, DEFAULT_RETRYABLE_CODES = Object.freeze([EMPTY_RESPONSE_CODE, "RATE_LIMIT", "SERVER", "TIMEOUT", "TRANSPORT"])). The guard exists so an attempt that produced nothing durable can be repeated; as written it cannot fire for the one shape where "nothing durable" is true and the user notices.
2. The question this guard wants to ask is already modelled in the release — assistantStreamHasVisibleContent / assistantStreamHasVisibleText (dsh-llm/lib/types/assistant-stream.js:282, :293, re-exported at dsh-llm/lib/index.js:2326). In the packages I read (dsh-llm, dsh-llm-deepseek, dsh-goal) I found no call site for either. (Their semantics do not fit this guard as written — see the fix section.)

Fix: ask for visible text or a tool call — and note that neither exported helper alone expresses that. Because this guard's own bug is "the predicate asks the wrong question", I read the two exported predicates' implementations instead of assuming their names describe their behaviour. They do not:

// dsh-llm/lib/types/assistant-stream.js
:282  export function assistantStreamHasVisibleContent(stream) {
:283    return stream.some(record => record.type === 'chunk'
:284      ? isVisibleChunk(record.chunk) : runFirstVisibleTime(record) !== undefined)

:204  export function isVisibleChunk(chunk) {
:206      case 'text-delta':
:207      case 'reasoning-delta':            //  ← reasoning counts as reader-visible
:208          return hasNonWhitespace(chunk.text)
…
:172  function blockIsVisible(block) {
:173      if (block.type === 'tool-call') return false   //  ← a tool call does not count

For this guard, assistantStreamHasVisibleContent is therefore wrong in both directions: a reasoning-only turn still counts as carrying visible content (the same failure as the predicate being reported), and a tool-call-only turn would be judged as having nothing visible. assistantStreamHasVisibleText (:293) excludes reasoning correctly but also excludes tool calls, so it is too narrow on its own. The intent here is the union — visible text OR a tool call. (These helpers also read the durable compact stream records, not the live order of opened blocks, so they are not drop-in at :1239 even where the semantics happen to line up.)

The predicate to use at this call site — filter by kind, not by "is there text". The blocks in order are built by open(kind) as { index, kind, text } (:1216-1223), and a reasoning block's text is non-empty too:

:1267  reasoningBlock.text += reasoning     // reasoning block, same `text` field
:1284  textBlock.text += content            // visible text block

So a predicate such as "some block has non-empty text" would classify a reasoning-only turn as visible and change nothing. The distinguishing field is kind (order blocks) / type (message blocks) — the two levels do not share a key name, which is easy to get wrong:

// order-level (the list this guard inspects):
order.some(b => b.kind === "tool-call" || (b.kind === "text" && b.text.trim().length > 0))

Narrow the trigger, don't blanket-retry. The guard should stay narrow: only a completed turn that produced neither text nor tool-call becomes EMPTY_RESPONSE. Two limits I want to state rather than leave for you to ask:

• If some flow legitimately finishes with reasoning only, that flow should be able to stay outside this guard — the intended narrowing is exactly "nothing visible was produced", so a turn that deliberately says nothing visible should be excluded by that flow's own contract, not by widening this predicate back.
• I have not verified what the client shows once retries are exhausted (dsh-llm/lib/index.js:235, DEFAULT_MAX_RETRIES = 5). The argument for retrying here is that the retry can only fire on a turn that had nothing visible to lose; whether the terminal state after 5 attempts needs its own message is a product decision I can't answer from the outside.

One thing I could not establish. In my environment the trigger shape is old but its ending is new: turns that stream only reasoning occur from 2026-08-31 onward, yet until 2026-09-11 every one of them ended aborted; from 09-11 13:18 local they end completed. The predicate and the reasoning path are byte-identical in 0.1.5-rc.1 and 0.1.5-rc.2 (same lines, :1239 / :1259), so this guard's logic is not what changed in my environment — I do not attribute the boundary to a specific change, and I am reporting it as an observation, not as a diagnosis.

Related but distinct. This is not the same gap as item 2 of the community's unfixed-issues list (#6520), where a reasoning-only turn is serialized as content: "" and every later turn of that session fails with a gateway 400. That is the serialization side. This one is the termination predicate: the turn is accepted as successfully finished in the first place, no error is raised, and nothing is retried. Same trigger shape, different layer — a fix in this layer may also reduce how often that one is reached, but it does not replace it.

Trigger. Any turn where the model streams reasoning but emits no text and no tool call.

Environment. @deepseek-ai/dsh-llm-deepseek@0.1.5-rc.2, @deepseek-ai/dsh-llm@0.1.5-rc.2. Line numbers are from the published package; :1213/:1216/:1222/:1236/:1239/:1257 were read directly and are quoted verbatim.

Revision note: an earlier version of this section recommended assistantStreamHasVisibleContent as the preferred fix on the grounds that it is official — I had recommended it without reading its implementation. I have now read it, it does not fit, and the recommendation is replaced above. Flagging it rather than quietly swapping, since the reasoning that produced the wrong recommendation (trusting a name because it is official) is the same reasoning this report is about.

Second revision note: an earlier version of this report carried the heading "why this looks like an oversight rather than intent". Having now read the rationale that ships with EMPTY_RESPONSE_CODE (quoted in that section), "oversight" is the wrong word — the predicate is faithful to the phrase the rationale itself uses ("carried no content blocks at all"), and a reasoning block is a content block. The claim is now narrower and stated in the code's own terms: the rationale and the phrasing part company on this shape. I would rather hold the smaller claim than the more flattering one.

Authorship note: reproduced and measured by me against my own store; root-cause tracing and drafting assisted by AI; verification and publication by me. I have no engineering background — if any technical claim reads wrong, please call it out; I will re-verify against the toolchain and correct.

Reported by the OfferKuai Team — Founder: Zhaofeng (Yaming). Website: https://www.offerkuai.com/ | Contact: contact@offerkuai.com

---

中文版 / ZH

摘要。 @deepseek-ai/dsh-llm-deepseek@0.1.5-rc.2 里有一道空响应守卫：本意是把"完成了但没有任何内容"的响应转成可重试的 EMPTY_RESPONSE 错误。但它判的是"有没有开过块"，而不是"有没有产出可见内容"——而流式吐出的一个 reasoning token 就会开一个 reasoning 块。于是一轮只吐 reasoning 的响应，永远满足守卫的反面情形，被当成正常完成上报：不重试，用户看到的是"这一轮结束了"但屏幕上什么都没有。

位置。

// dsh-llm-deepseek/lib/index.js
:1213  const order = [];
:1216  function open(kind) {
:1222    order.push(block)                       //  ← 每开一个块都落进这里
:1236  const reason = pendingFinish ?? { kind: "stop" };
:1239  reason: reason.kind === "stop" && order.length === 0
:1240    ? { kind: "error", failure: { message: "model returned a completed response with no content",
:1243                                 code: EMPTY_RESPONSE_CODE } }
:1245    : reason
:1257  if (typeof reasoning === "string" && reasoning.length > 0) {
:1258    if (!reasoningBlock) { reasoningBlock = open("reasoning"); … }   //  ← 开了一个块

只吐 reasoning 的一轮恰好开了一个块 ⇒ order.length === 0 为假 ⇒ 守卫被绕过，落到 { kind: "stop" }。

这道守卫「是为了什么」——用发布自己的话。 理由就写在那个常量旁边：

// packages/llm/llm/src/error.ts:28-37
 * Canonical provider-neutral code for a response that completed normally but
 * carried no content blocks at all. Providers occasionally emit a degenerate
 * completion (a terminal stop with zero output); adapters classify it as this
 * failure instead of yielding an empty assistant message, because an empty
 * message silently ends the turn with nothing for the user or the loop to act
 * on. The attempt produced nothing durable, so retry policy treats it as safe
 * to repeat.

（译：该常量用于"正常完成、但完全没有内容块"的响应。供应商偶尔会产出这种退化完成（一次输出为空的终止 stop）；适配器把它归类为这个 failure，而不是产出一条空的 assistant 消息——因为一条空消息会静默结束这一轮，让用户和循环都没有东西可作用。该次尝试没有留下任何持久产物，所以重试策略认为重复是安全的。）

这条理由说的是效果：一轮结束时"用户和循环都没有东西可作用"。而只吐 reasoning 的一轮，恰恰就是这个效果。但那个谓词，是忠于它书写时所依据的措辞——"完全没有内容块"——而 reasoning 块就是一个内容块。所以我并不主张这道守卫违背了它自己的意图；我主张的是：在这个形状上，"已声明的理由"与"谓词的措辞"分岔了，而抵达代码的是措辞。同一份发布里还有两处旁证：

1. EMPTY_RESPONSE_CODE 是默认可重试集里的第一位——dsh-llm/lib/index.js:236-242（DEFAULT_MAX_RETRIES = 5，DEFAULT_RETRYABLE_CODES = Object.freeze([EMPTY_RESPONSE_CODE, "RATE_LIMIT", "SERVER", "TIMEOUT", "TRANSPORT"])）。这道守卫存在的意义，是让"没有留下任何持久产物"的那次尝试可以被重试；而按现在的写法，它恰恰在"确实什么都没留下、且用户看得见"的那个形状上永不触发。
2. 这道守卫想问的那个问题，在该发布里已被建模——assistantStreamHasVisibleContent / assistantStreamHasVisibleText（dsh-llm/lib/types/assistant-stream.js:282, :293，经 dsh-llm/lib/index.js:2326 再导出）。在我读过的包里（dsh-llm、dsh-llm-deepseek、dsh-goal）未发现调用点（我没有全仓扫描，所以这是"我读过的包内无调用点"，不是"全仓都没用"）。（但它们的语义并不适配这道守卫，见下"修法"段。）

修法：请把判据改为"有可见文本 或 有工具调用"——并且注意：两个已导出的判据单独都表达不了这件事。 因为这道守卫自己的毛病就是"问错了问题"，所以这次我读了这两个导出判据的实现，而不是假定函数名描述了它的行为。它们不符合：

// dsh-llm/lib/types/assistant-stream.js
:282  export function assistantStreamHasVisibleContent(stream) {
:283    return stream.some(record => record.type === 'chunk'
:284      ? isVisibleChunk(record.chunk) : runFirstVisibleTime(record) !== undefined)

:204  export function isVisibleChunk(chunk) {
:206      case 'text-delta':
:207      case 'reasoning-delta':            //  ← reasoning 被算作"读者可见"
:208          return hasNonWhitespace(chunk.text)
…
:172  function blockIsVisible(block) {
:173      if (block.type === 'tool-call') return false   //  ← 工具调用反而**不算**

所以对这道守卫而言，assistantStreamHasVisibleContent 两个方向都错：只吐 reasoning 的一轮仍被算作有可见内容（即与本报告所指控的失效完全相同），而"只调用工具、不吐文本"的一轮会被判成"什么都没看见"。assistantStreamHasVisibleText（:293）正确地排除了 reasoning，但也排除了工具调用，因而单独用又太窄。这里的意图是两者的并集——有可见文本，或有工具调用。（另外，这两个函数读的是持久化的紧凑 stream 记录，不是守卫检查的那张实时 order 表，所以即便语义对得上，在 :1239 处也不是直接替换。）

在这个调用点上应使用的谓词——按 kind 过滤，不要用"有没有 text"。 order 里的块由 open(kind) 构造成 { index, kind, text }（:1216-1223），而 reasoning 块的 text 同样是非空的：

:1267  reasoningBlock.text += reasoning     // reasoning 块，同样的 `text` 字段
:1284  textBlock.text += content            // 可见文本块

所以像"只要某块 text 非空就算可见"这样的谓词，会把只吐 reasoning 的一轮判成"有可见内容"，等于什么都没改。真正的区分字段是 kind（order 块）/ type（消息级块）—— 这两层不共用同一个键名，很容易写错：

// order 级（也就是本守卫检查的那张表）：
order.some(b => b.kind === "tool-call" || (b.kind === "text" && b.text.trim().length > 0))

把触发条件收窄，不要一巴掌重试。 守卫应当保持窄：只有"既没有 text 也没有 tool-call"的完成轮才变成 EMPTY_RESPONSE。有两点我主动说清、不留给追问：

• 若某些流程本来就该只思考不输出，那应当由那些流程自己的契约把它排除在外，而不是反过来把这个谓词放宽。
• 我没有核实"重试耗尽后客户端显示什么"（dsh-llm/lib/index.js:235，DEFAULT_MAX_RETRIES = 5）。在这里重试之所以站得住，是因为它只能作用在"本来就没有任何可见内容可丢"的轮次上；至于 5 次之后那个终态是否该有自己的提示，那是产品决策，我从外部答不了。

有一件事我没能确定。 在我的环境里，触发形状是旧的，但结局是新的：只吐 reasoning 的轮次从 2026-08-31 起就有，但直到 2026-09-11 之前它们每一例都以 aborted 结束；自本地时间 09-11 13:18 起，它们以 completed 结束。而该谓词与 reasoning 写入路径在 0.1.5-rc.1 与 0.1.5-rc.2 中逐字相同（同为 :1239 / :1259）—— 所以在我这个环境里，变的不是这道守卫的逻辑；我对这个时间边界不做归因，只作为观察报告，不作为诊断。

相关但不同。 这不是社区未修清单（#6520）第 2 条那件事——那里是纯推理轮被序列化成 content: ""，导致该会话此后每轮都被网关 400。那是序列化侧。本条是终止判据：这类轮次一开始就被当成正常结束，不报错、不重试。触发形状相同、层不同——修好本层可能减少撞上那一层的次数，但不能替代它。

触发条件。 任何"模型只吐 reasoning、不吐文本也不调工具"的轮次。

环境。 @deepseek-ai/dsh-llm-deepseek@0.1.5-rc.2、@deepseek-ai/dsh-llm@0.1.5-rc.2。行号取自已发布包，:1213 / :1216 / :1222 / :1236 / :1239 / :1257 均为逐字读取。

修正说明：本段早先的版本把 assistantStreamHasVisibleContent 作为首选修法推荐，理由是"它是官方的"——我没有读它的实现就推荐了。现已读过：它不适配，上面的分析取代了那条推荐。我选择把这次修正标出来，而不是悄悄替换，因为产生那条错误推荐的推理——"因为是官方的，就免于验证"——正是本报告在讲的那个推理。

第二处修正说明：本报告早先有一个小标题写作"为什么更像疏漏而不像有意"。在读过 EMPTY_RESPONSE_CODE 随代码一起发布的理由之后（已引在该段）——"疏漏"这个词用错了：那个谓词是忠于理由本身所用的措辞（"完全没有内容块"）写的，而 reasoning 块就是一个内容块。现在的说法更窄，而且用的是代码自己的术语：理由与措辞在这个形状上分岔。我宁可持一个更小的主张，而不是一个更好看的主张。

声明：本次实测与统计由我针对自己的数据完成；根因追查与文稿撰写由 AI 辅助；核验与发布由我本人负责。我没有工程背景 —— 若任何技术表述有误，请直接指出，我会对照工具链重新核实并更正。

本报告由 OfferKuai（Offer快）团队提交 —— 创始人：Zhaofeng（Yaming）。官网：https://www.offerkuai.com/ | 联系：contact@offerkuai.com

[PerryLink]

Confirmed against master c291e79 — your report is accurate, including the
published-lib line numbers mapping onto these source lines.

• The guard: packages/llm/llm-deepseek/src/translate.ts:132-141 — at [DONE],
  reason.kind === 'stop' && order.length === 0 becomes the EMPTY_RESPONSE
  error, else the stop passes through unchanged.
• The hole: a streamed reasoning token opens a block BEFORE that check —
  translate.ts:158-164 (reasoningBlock = open('reasoning')). A reasoning-only
  turn therefore always has order.length >= 1 and the guard can never fire for
  the one shape it most needs to catch.
• Cross-checks: EMPTY_RESPONSE_CODE is defined at
  packages/llm/llm/src/error.ts:39 and sits in the default retryable set
  (packages/llm/llm/src/retry-policy.ts:19). assistantStreamHasVisibleContent
  exists at packages/llm/llm/src/assistant-stream.ts:349 and, as you found, has
  no production call site (grep: only tests and README reference it).
• This is the same predicate as A reasoning-only turn is reported as `completed`: no answer, no tool call, and the raw reasoning is left on screen #6431 (verified there: reasoning-only turns
  serialize to no visible content). Your framing is right and useful: this is
  the TERMINATION predicate, DSH master (0.1.6-alpha.2 / ddefc45fbc) 仍未修复的问题清单（社区核实版） #6520-item-2 is the SERIALIZATION side — fixing
  this layer reduces how often that one is reached but does not replace it.

Fix direction for maintainers: your proposal is the natural seam — replace the
block-count predicate with the visible-content question
(assistantStreamHasVisibleContent, or an
order.some(b => b.kind === 'text' || b.kind === 'tool-call') predicate). I
agree with your boundary: keep the trigger narrow, and the retry-exhaustion UX
remains a product decision.

[yamingmou]

Thanks — the source mapping is the useful part: packages/llm/llm-deepseek/src/translate.ts:132-141 for the guard and :158-164 for the block that reasoning opens, plus error.ts:39 and retry-policy.ts:19. Anyone can now check the behaviour from src rather than from a build.

One correction to the fix direction, and it is the same trap the report is about. assistantStreamHasVisibleContent is not a safe substitute at this call site. I read its implementation rather than assuming the name describes it:

// packages/llm/llm/src/assistant-stream.ts
:349  export function assistantStreamHasVisibleContent(stream) { … isVisibleChunk(record.chunk) … }

      export function isVisibleChunk(chunk) {
        case 'text-delta':
        case 'reasoning-delta':          //  ← reasoning counts as reader-visible
          return hasNonWhitespace(chunk.text)

      function blockIsVisible(block) {
        if (block.type === 'tool-call') return false   //  ← a tool call does not count

So for this guard it is wrong in both directions: a reasoning-only turn still counts as carrying visible content (the reported shape would remain unfixed), and a tool-call-only turn would be judged as having nothing visible. It also consumes the durable compact stream records, not the live order the guard inspects, so it is not drop-in here even where the semantics line up.

The shape that matches the guard's intent is the one you gave as the alternative — a union of visible text and tool calls, evaluated on order and filtered by kind (the order blocks are { index, kind, text }, while message-level blocks use type; the two levels do not share a key name):

order.some(b => b.kind === 'tool-call' || (b.kind === 'text' && b.text.trim().length > 0))

The trim() is the only addition to your version: an empty or whitespace-only text block should not count as visible, and text blocks are created before their content arrives. (The blocks in order also carry non-empty text for reasoning — reasoningBlock.text += reasoning — which is exactly why the filter has to be on kind and not on "has text".)

On your cross-references: #6431 as the serialization side of the same predicate matches what I see, and yes — fixing this layer reduces how often that one is reached without replacing it. Keeping the trigger narrow and treating the post-retry terminal state as a product decision is the same boundary I drew.

For completeness: an earlier revision of my post recommended assistantStreamHasVisibleContent as the preferred fix on the grounds that it is official, without reading it. I revised the post after reading it, and the fix section now carries that correction. Flagging it because the reasoning that produced the wrong recommendation is the same reasoning this report is about — a name trusted because it is official.

Authorship note: reproduced and measured by me against my own store; root-cause tracing and drafting assisted by AI; verification and publication by me. I have no engineering background — if any technical claim reads wrong, please call it out; I will re-verify against the toolchain and correct.

Reported by the OfferKuai Team — Founder: Zhaofeng (Yaming). Website: https://www.offerkuai.com/ | Contact: contact@offerkuai.com

---

中文版 / ZH

谢谢 —— 你给源码位点这部分最有用：守卫在 packages/llm/llm-deepseek/src/translate.ts:132-141，reasoning 开块在 :158-164，加上 error.ts:39 与 retry-policy.ts:19。这样任何人都能从 src 而不是从构建产物复核该行为。

修法方向上有一处更正，而且它正是本报告在讲的那个坑。 assistantStreamHasVisibleContent 在这个调用点上不能当作替代品。我读了它的实现，而不是假定函数名描述了它的行为：

// packages/llm/llm/src/assistant-stream.ts
:349  export function assistantStreamHasVisibleContent(stream) { … isVisibleChunk(record.chunk) … }

      export function isVisibleChunk(chunk) {
        case 'text-delta':
        case 'reasoning-delta':          //  ← reasoning 被算作"读者可见"
          return hasNonWhitespace(chunk.text)

      function blockIsVisible(block) {
        if (block.type === 'tool-call') return false   //  ← 工具调用反而**不算**

所以对这道守卫而言，它两个方向都错：只吐 reasoning 的一轮仍被算作有可见内容（即所报形状不会被修好），而"只调用工具"的一轮会被判成什么都没看见。此外，它读的是持久化的紧凑 stream 记录，不是守卫检查的那张实时 order —— 即便语义对得上，在这里也不是直接替换。

与守卫意图相符的形状，就是你给出的那个备选 —— "可见文本 ∪ 工具调用"，在 order 上按 kind 过滤（order 的块是 { index, kind, text }，而消息级块用 type；两层不共用键名）：

order.some(b => b.kind === 'tool-call' || (b.kind === 'text' && b.text.trim().length > 0))

相比你的版本只多一个 trim()：空白文本块不该算"可见"，而文本块在内容到达之前就已创建。（另外，order 里 reasoning 块的 text 也是非空的 —— reasoningBlock.text += reasoning —— 这正是过滤必须落在 kind 上、而不能落在"有没有 text"上的原因。）

关于你的交叉引用： #6431 作为同一谓词的序列化侧，与我所见一致；而且是的——修这一层会减少撞上那一层的次数，但不替代它。把触发条件保持窄、把"重试耗尽后的终态"视为产品决策，也是我画的同一条边界。

补充一句完整性说明：我的帖子早先的版本曾以"它是官方的"为由，把 assistantStreamHasVisibleContent 作为首选修法推荐，当时没有读它。读过之后我改了帖子，修法段现在带着那处更正。我把这件事标出来，是因为产生那条错误推荐的推理——因为一个名字"是官方的"就免于验证——正是本报告在讲的推理。

声明：本次实测与统计由我针对自己的数据完成；根因追查与文稿撰写由 AI 辅助；核验与发布由我本人负责。我没有工程背景 —— 若任何技术表述有误，请直接指出，我会对照工具链重新核实并更正。

本报告由 OfferKuai（Offer快）团队提交 —— 创始人：Zhaofeng（Yaming）。官网：https://www.offerkuai.com/ | 联系：contact@offerkuai.com

[yamingmou]

Evidence chain for the main post — six steps, all read from the published package.

Every :line below is a line in the published build output (dsh-llm-deepseek/lib/index.js). The same statements exist in source at packages/llm/llm-deepseek/src/translate.ts — the guard at :132-141, the reasoning block at :158-164 — which is the better place to check them if you prefer source to build output. I read both; they say the same thing.

1 · A step's blocks are recorded in one ordered list

// dsh-llm-deepseek/lib/index.js
:1213  const order = [];
:1216  function open(kind) {
:1217    const block = { index: nextIndex++, kind, text: "" };
:1222    order.push(block)                        // every opened block lands here
:1223    return block

order is not "the blocks that said something" — it is every block that was opened, in order. The variable that the empty-response guard inspects is this one.

2 · A reasoning token opens a block

:1257  if (typeof reasoning === "string" && reasoning.length > 0) {
:1258    if (!reasoningBlock) {
:1259      reasoningBlock = open("reasoning")     // ← opens a block

So any streamed reasoning — even a single token, even if it is the only thing the model sends — puts at least one entry into order.

3 · The guard asks about order, not about content

:1236  const reason = pendingFinish ?? { kind: "stop" };
:1239  reason: reason.kind === "stop" && order.length === 0
:1240    ? { kind: "error", failure: {
:1241        message: "model returned a completed response with no content",
:1243        code: EMPTY_RESPONSE_CODE } }
:1245    : reason

The declared intent (the comment at :1206 reads "…'EMPTY_RESPONSE' error finish instead of a successful empty message") is to catch a completed response that produced nothing. The predicate implements "nothing" as "no block was opened" — which is a different question from "nothing visible was produced".

4 · Therefore the guard cannot fire for this shape

A turn that streams only reasoning opens exactly one block ⇒ order.length === 0 is false ⇒ the ternary falls through to reason, i.e. { kind: "stop" } ⇒ the turn is a normal completion. No error, no retry, and the visible result is empty.

The two block kinds that a user can actually see are text and tool-call; neither is consulted anywhere in this decision.

5 · The retry machinery is already wired to the code the guard never emits

// dsh-llm/lib/index.js
:235  const DEFAULT_MAX_RETRIES = 5;
:236  const DEFAULT_RETRYABLE_CODES = Object.freeze([
:237    EMPTY_RESPONSE_CODE, "RATE_LIMIT", "SERVER", "TIMEOUT", "TRANSPORT" ]);

EMPTY_RESPONSE is the first entry of the default retryable set. So the cost of making the predicate ask the right question is not "a new behaviour" — it is switching on a path that already exists and is already configured to retry (up to 5 attempts).

The intent behind that code sits in the shipped source next to the code itself:

// packages/llm/llm/src/error.ts:28-37
 * ... adapters classify it as this failure instead of yielding an empty assistant
 * message, because an empty message silently ends the turn with nothing for the
 * user or the loop to act on. The attempt produced nothing durable, so retry
 * policy treats it as safe to repeat.

A reasoning-only turn does end the turn with nothing for the user or the loop to act on — which is the case this rationale rules out. Its literal wording is "carried no content blocks at all", and a reasoning block is a content block; so I read this as a gap between the stated rationale and the guard's phrasing, not as a missing intent. That distinction is the reason the fix below narrows the condition rather than widening the rationale.

6 · The release ships two predicates in this area — neither expresses this guard's intent

In the published build they are dsh-llm/lib/types/assistant-stream.js:282 / :293, re-exported from index.js:2326. In source the first one reads:

// packages/llm/llm/src/assistant-stream.ts:349
export function assistantStreamHasVisibleContent(stream: readonly AssistantStreamRecord[]): boolean {
  return stream.some(record => record.type === 'chunk'
    ? isVisibleChunk(record.chunk)
    : runFirstVisibleTime(record) !== undefined)
}

It delegates to isVisibleChunk, which counts a non-whitespace reasoning-delta as reader-visible — the same shape this report is about — and blockIsVisible returns false for a tool-call. So using it here would change nothing for the reported defect, and would additionally misjudge a turn that only calls tools. Its sibling assistantStreamHasVisibleText excludes reasoning correctly, but excludes tool calls as well, so on its own it is too narrow.

The predicate this guard actually wants is visible text or a tool call:

order.some(b => b.kind === "tool-call" || (b.kind === "text" && b.text.trim().length > 0))

Both helpers read persisted compact records (AssistantStreamRecord[]), not the live order this guard inspects, so neither is a drop-in replacement at that call site. In the packages I read (dsh-llm, dsh-llm-deepseek, dsh-goal) I found no call site for either — I did not scan the whole repository, so this is "no call site in the packages I read", not "unused everywhere".

7 · What I measured in my own store

A scan of my own session logs — 285 files, 3,973 turns, of which 3,320 end completed — finds 21 turns whose turn/end is completed while no step in that turn produced text or tool-call (every assistant/message block in the turn was reasoning): 0.63% of completed turns.

Denominator, because one session is not a sample. All 21 sit inside a single long-running session; that session has 1,006 turns, 890 of them completed, so inside it the shape is 21 / 890 = 2.4%. They are not one contiguous block: the 21 split into 13 separate runs spread across turns 946–1145 (largest gap 48 turns), so this is 21 independent observations rather than a single incident counted repeatedly. (That session also exists in my migrated copy; the two store counts I get are the same 21 turns, not 42.)

The trigger is old; the ending is not. Counting turns that stream reasoning and nothing else, regardless of how they end:

window	reasoning-only turns	how they ended
2026-08-31 → 09-11 01:26	18	all aborted — not one completed
2026-09-11 13:18 → 09-13	21	all completed (aborted still occurs in the same window: 3 + 1)

The shape itself is therefore not new — it goes back to 08-31 — but being accepted as a normal completion starts 09-11 in my store. Across that boundary it is the same session, the same writer and the same log format, so this is not a logging-format artefact.

One reading of that boundary — offered as an observation, not a diagnosis. Before 09-11 these turns ended aborted: the turn was terminated by a cancellation, which is a larger event than the stream itself, so the question "did this response produce anything?" never had to be answered — the guard was never exercised. From 09-11 they finish normally, so they reach the guard for the first time, and it fails on the first contact. If that reading is right, then what happened is not "a change introduced this defect" but "something upstream stopped aborting these turns, which uncovered a defect that had been latent all along" — consistent with the predicate being byte-identical across the two rc builds. I cannot verify the upstream side from here, so this stays a reading; the two facts above are the observation.

What this is not. It is not attributable to the predicate: the guard and the reasoning path are byte-identical in 0.1.5-rc.1 and 0.1.5-rc.2 (:1239 / :1259 in both). Two environment facts sit near that boundary and neither lands on 09-11: my request headers changed maxTokens from 256000 to 65536 on 09-09 18:48, and my desktop build (2.0.9) was updated 09-10 22:20. I report the boundary as an observation, not as a diagnosis.

Boundary of this evidence. All of it is from my store; blocks are classified by event type, not by re-running the model. It shows that the shape occurs, how it is terminated, and when the termination changed — it does not explain why.

8 · One correction I made to the main post, in the open

The main post's fix section originally recommended assistantStreamHasVisibleContent as the preferred fix, on the grounds that it is the official helper. I had not read its implementation when I wrote that. I have now: it delegates to isVisibleChunk, which counts a non-whitespace reasoning-delta as reader-visible (assistant-stream.js:206-208) and counts a tool-call as not visible (:173). For this guard that is wrong in both directions, so the recommendation was wrong, and I revised the post rather than leaving it. The section now carries the correction and the reasoning behind the mistake, which is the same reasoning this report is about: a name was trusted because it was official. If you read the post before this revision, re-read the fix section.

Authorship note: reproduced and measured by me against my own store; root-cause tracing and drafting assisted by AI; verification and publication by me. I have no engineering background — if any technical claim reads wrong, please call it out; I will re-verify against the toolchain and correct.

Reported by the OfferKuai Team — Founder: Zhaofeng (Yaming). Website: https://www.offerkuai.com/ | Contact: contact@offerkuai.com

---

中文版 / ZH

主帖的证据链 —— 六步，全部读自已发布包。

下文每个 :行号 都是发布构建产物（dsh-llm-deepseek/lib/index.js）里的行。同样的语句在源码里位于 packages/llm/llm-deepseek/src/translate.ts —— 守卫在 :132-141、reasoning 开块在 :158-164 —— 若你更愿意看源码而不是构建产物，那是更好的核对位置。两边我都读过，说法一致。

1 · 一个 step 的块被记进同一个有序表

// dsh-llm-deepseek/lib/index.js
:1213  const order = [];
:1216  function open(kind) {
:1217    const block = { index: nextIndex++, kind, text: "" };
:1222    order.push(block)                        // 每开一个块都落进这里
:1223    return block

order 记的不是"说了话的块"，而是"被开过的块"。而空响应守卫检查的，正是这一张表。

2 · 一个 reasoning token 就会开一个块

:1257  if (typeof reasoning === "string" && reasoning.length > 0) {
:1258    if (!reasoningBlock) {
:1259      reasoningBlock = open("reasoning")     // ← 开了一个块

所以任何流式 reasoning——哪怕只有一个 token、哪怕它是模型唯一吐出的东西——都会往 order 里放进至少一条。

3 · 守卫问的是 order，不是内容

:1236  const reason = pendingFinish ?? { kind: "stop" };
:1239  reason: reason.kind === "stop" && order.length === 0
:1240    ? { kind: "error", failure: {
:1241        message: "model returned a completed response with no content",
:1243        code: EMPTY_RESPONSE_CODE } }
:1245    : reason

声明意图（:1206 的注释原文："…'EMPTY_RESPONSE' error finish instead of a successful empty message"）是拦住"完成了但什么都没产出"的响应。而谓词把"什么都没产出"实现成了**"没有开过块"——这跟"没有产出可见内容"是两个不同的问题**。

4 · 于是这个形状上守卫永不触发

只吐 reasoning 的一轮恰好开了一个块 ⇒ order.length === 0 为 false ⇒ 三元落到 reason，即 { kind: "stop" } ⇒ 该轮是正常完成：不报错、不重试，而用户看到的结果是空的。

用户真正能看到的两种块是 text 与 tool-call——在这段判定里一个都没被问到。

5 · 重试机制早已接在"守卫永远不会发出的那个码"上

// dsh-llm/lib/index.js
:235  const DEFAULT_MAX_RETRIES = 5;
:236  const DEFAULT_RETRYABLE_CODES = Object.freeze([
:237    EMPTY_RESPONSE_CODE, "RATE_LIMIT", "SERVER", "TIMEOUT", "TRANSPORT" ]);

EMPTY_RESPONSE 是默认可重试集里的第一位。所以把谓词改成问对的问题，不是引入新行为，而是接通一条已经存在、且已经配好重试（最多 5 次）的通路。

而这段代码背后的设计意图，就写在发布源码里、紧挨着代码：

// packages/llm/llm/src/error.ts:28-37
 * ... adapters classify it as this failure instead of yielding an empty assistant
 * message, because an empty message silently ends the turn with nothing for the
 * user or the loop to act on. The attempt produced nothing durable, so retry
 * policy treats it as safe to repeat.

（译：适配器把它归类为这个 failure，而不是产出一条空的 assistant 消息——因为一条空消息会静默结束这一轮，让用户和循环都没有东西可作用。该次尝试没有留下任何持久产物，所以重试策略认为重复是安全的。）

而"只吐 reasoning 的一轮"，恰恰就是结束了一轮、而用户和循环都没有东西可作用——正是这条意图要排除的情形。它的字面措辞是"完全没有内容块"，而 reasoning 块就是一个内容块；所以我把这件事读作**"已声明的意图"与"守卫的措辞"之间的落差**，而不是"意图缺失"。这个区分正是下面那条修法收窄条件、而不是放宽意图的原因。

6 · 这个区域里该发布带了两个判据，但两个都不表达这道守卫的意图

在发布构建产物里它们是 dsh-llm/lib/types/assistant-stream.js:282 / :293，并经 index.js:2326 再导出。源码里第一个长这样：

// packages/llm/llm/src/assistant-stream.ts:349
export function assistantStreamHasVisibleContent(stream: readonly AssistantStreamRecord[]): boolean {
  return stream.some(record => record.type === 'chunk'
    ? isVisibleChunk(record.chunk)
    : runFirstVisibleTime(record) !== undefined)
}

它转调 isVisibleChunk，而后者把"非空白的 reasoning-delta"算作读者可见——正是本报告讲的那个形状；并且 blockIsVisible 对 tool-call 返回 false。所以拿它当修法，对已报缺陷等于零改动，还会额外误判"只调工具"的轮次。它的同族 assistantStreamHasVisibleText 正确排除了 reasoning，但连工具调用一起排除，单独用太窄。

这道守卫真正想要的判据是 可见文本 或 工具调用：

order.some(b => b.kind === "tool-call" || (b.kind === "text" && b.text.trim().length > 0))

两个 helper 读的都是持久化紧凑记录（AssistantStreamRecord[]），不是这道守卫检查的那张实时 order ⇒ 在该调用点上都不是可直接替换的。在我读过的包里（dsh-llm、dsh-llm-deepseek、dsh-goal）未发现调用点——我没有全仓扫描，所以这是"我读过的包内无调用点"，不是"全仓都没用"。

7 · 我在自己的样本里量到的东西

对我自己的会话日志做了一次扫描 —— 285 个文件、3,973 个 turn，其中 3,320 个以 completed 结束 —— 找到 21 个 turn：其 turn/end 是 completed，而该 turn 内没有任何 step 产出 text 或 tool-call（整个 turn 的 assistant/message 块全是 reasoning）：占 completed 的 0.63%。

分母 —— 因为"一个会话"不能当样本。 这 21 例全部在同一个长期会话里；该会话共 1,006 个 turn，其中 890 个 completed ⇒ 在它内部，该形状占 21 / 890 = 2.4%。而且它们不是一整块连续：21 例分成 13 段、散布在 turn 946–1145 之间（最大间隔 48 个 turn）⇒ 这是 21 个独立观察，不是"同一个事件被重复计数"。（该会话在我的迁移副本里也存在；我得到的两组库计数是同样的 21 个 turn，不是 42。）

触发形状是旧的，结局是新的。 统计"只吐 reasoning、别的什么都不吐"的 turn（不论怎么结束）：

窗口	只吐 reasoning 的 turn	结局
2026-08-31 → 09-11 01:26	18	全部 aborted —— 一例 completed 都没有
2026-09-11 13:18 → 09-13	21	全部 completed（同一窗口里 aborted 仍会发生：3 + 1 例）

所以形状本身不新——最早可追到 08-31；但"被当作正常完成"是在 09-11 才开始的（在我的样本里）。跨过这个边界的是同一个会话、同一个写作方、同一种日志格式，所以这不是日志格式造成的假象。

对这个边界的一种读法——作为观察提出，不作为诊断。 09-11 之前这些轮次以 aborted 结束：那是被"取消"终止，而取消是一个比流本身更大的事件，于是"这一轮到底有没有产出东西"这个问题从没被问过——守卫从未被检验。09-11 之后它们正常完成，于是第一次走到守卫面前，而守卫在第一次接触时就失效了。如果这个读法成立，那么发生的不是"某次改动引入了这个缺陷"，而是"上游不再 abort 这类轮次，顺带把一个一直潜伏的缺陷暴露了出来"——这与"谓词在两个 rc 构建里逐字相同"是一致的。上游那一侧我在这里无法验证，所以它只是一个读法；上面两条是观察。

这不能归因于哪个东西。 它不能归因于该谓词：守卫与 reasoning 写入路径在 0.1.5-rc.1 与 0.1.5-rc.2 之间逐字相同（同为 :1239 / :1259）。边界附近有两件环境事实，但都不落在 09-11：我的请求头在 09-09 18:48 把 maxTokens 从 256000 改成 65536；我的桌面构建（2.0.9）在 09-10 22:20 更新过。我把这个边界当观察报告，不当诊断。

这份证据的边界。 以上全部来自我的样本；块分类依据的是事件类型，不是重跑模型。它能说明"该形状确实发生、如何被收尾、以及收尾方式何时变了"——它不解释为什么。

8 · 我对主帖做过的一处修正（公开说明）

主帖的修法段最初把 assistantStreamHasVisibleContent 作为首选修法推荐，理由是"它是官方 helper"——写那段时我没有读它的实现。现在读过了：它转调 isVisibleChunk，而后者把"非空白的 reasoning-delta"算作读者可见（assistant-stream.js:206-208），并把 tool-call 算作不可见（:173）。对这道守卫而言两个方向都错，所以那条推荐是错的，我改了帖子而不是留着。修法段现在带着这处修正，以及产生那个错误的推理——因为一个名字"是官方的"就免于验证——而这正是本报告在讲的推理。如果你在我修正之前读过主帖，请重读修法段。

声明：本次实测与统计由我针对自己的数据完成；根因追查与文稿撰写由 AI 辅助；核验与发布由我本人负责。我没有工程背景 —— 若任何技术表述有误，请直接指出，我会对照工具链重新核实并更正。

本报告由 OfferKuai（Offer快）团队提交 —— 创始人：Zhaofeng（Yaming）。官网：https://www.offerkuai.com/ | 联系：contact@offerkuai.com

[PerryLink]

Thanks — this correction is right, and I verified it against source at c291e79. My earlier endorsement of assistantStreamHasVisibleContent as the fix seam was wrong for this call site, in exactly the two directions you describe:

1. It would not fire for the reported shape. assistantStreamHasVisibleContent (packages/llm/llm/src/assistant-stream.ts:349-353) delegates to isVisibleChunk (:270-282), and a non-whitespace reasoning-delta counts as visible there (:273-274). A reasoning-only turn is therefore "visible" to it, and the guard keeps passing it through — the defect survives unchanged.
2. It would fire for a turn that did work. blockIsVisible returns false for tool-call blocks (:238-242), so a tool-call-only turn reads as "no visible content" and would be retried as empty — the opposite mistake.

The shape mismatch is real too: both helpers take persisted AssistantStreamRecord[] (compact records), while the guard inspects the live OpenBlock[] list built in translate.ts:116-124 — record kinds vs block kinds, so neither is a drop-in at :135.

Your proposed predicate is the right one at this site:

order.some(b => b.kind === 'tool-call' || (b.kind === 'text' && b.text.trim().length > 0))

Two confirmations from source: a tool-call block is only opened when the model actually emits a tool_calls delta (translate.ts:177-183), so it can't false-positive on an empty tool block; and OpenBlock.text accumulates only non-empty deltas for text blocks (:167-175), so the trim() check is doing real work for whitespace-only text. The retry side stands as established earlier in this thread: EMPTY_RESPONSE_CODE is already first in the default retryable set, so the narrowed predicate switches on a path that already retries — no new behavior beyond the question it asks.

Your measured 0.63% (2.4% within the long session) and the 09-11 boundary are useful. The "upstream stopped aborting these turns, exposing a latent defect" reading is the most consistent one I can see from here — the predicate being byte-identical across the two rc builds supports it — though like you I can't verify the upstream side.

For the record: my earlier comment's fix suggestion should be read with your correction applied — the helper is the wrong tool here; the inline order.some predicate is the seam. Thanks for re-verifying instead of taking the official name on faith.

---