plugin-hono-server 适配器把逃出 handler 的抛出整个丢弃：裸 500 + 零日志（#4264 只按路由治了标）

[hotlong]

在 cloud#1097（生产控制面 5xx 定位）里核到的，与那单无关，是独立问题。未 assign，交 PM 分诊。

事实

packages/plugins/plugin-hono-server/src/adapter.ts，framework main f886f291：

• runHandler() 跑路由 handler，handler 一旦 reject：

  }).catch((_err) => {
      _endHandler?.();
      closeStream();
      resolve({ response: null, failed: true });
  });
  

  参数名就叫 _err——被显式丢弃，没有任何日志。

• wrap() 于是回兜底响应：

  return response ?? c.json({ error: 'No response from handler' }, 500);
  

净效果：任何逃出 handler 的抛出，在这个平台上表现为

1. 一个 非信封 的 500（error 是裸字符串、无 success、无 error.message、无 code），且
2. 任何地方都没有日志——原因彻底消失，连 stack 都没有。

为什么这不是 #4264 的重复

#4264（已关闭）诊断的正是这段代码，原文写得很准：「handler 的 rejection 被吞掉…真实原因彻底丢失（甚至没有日志）」。但它的修法是按路由加 catch（三条 datasource 路由），接缝本身没动——上面这段在 main 上一字未改。所以：

• 该结论仍然成立，只是从「三条路由的契约缺口」变成「最后一道兜底接缝没有诊断出口」；
• 每新增一条路由就要重新记得包 catch，正是 Three datasource routes still surface a service throw as the adapter's non-envelope 500 (#4249 follow-up) #4264 描述的那种「一个平台不变量在第二处被重新实现」的税；
• scripts/check-route-envelope.mjs 结构上看不到这一类（Three datasource routes still surface a service throw as the adapter's non-envelope 500 (#4249 follow-up) #4264 也说了：它审计响应写点，未捕获的抛出根本不写响应）。

建议方向（待裁决，不预设）

至少要有日志：在 .catch 里把错误按 serializeError 那类不丢 message/stack 的形状打出来（Error 的 message/stack 是 non-enumerable，直接塞进结构化 meta 会变成 {}——cloud objectos-runtime/src/safe-log.ts 的头注释把这个坑写全了）。

是否顺带把兜底 body 收成声明信封是另一个决策（会改线上响应形状），建议单独裁决，不要和「补日志」捆绑——补日志是纯增益、零风险的那一半。

影响到谁

任何以这个适配器为 transport 的 host。具体动机：ObjectStack Cloud 的控制面在生产上出现过裸 5xx 而日志里什么都没有；cloud 侧只能在自己的路由里逐条 try/catch + rethrow 去补（cloud#1144 对 POST /cloud/licenses/issue 就是这么做的），而那显然是在替这个接缝还债。

证据强度

强：main 上的代码直读，无需复现环境。

---

Generated by Claude Code

[os-zhuang]

分诊:pm:queue + domain:cli。

落点锚定理由(⛔ 不按标题词汇猜)

修复落在 packages/plugins/plugin-hono-server/src/adapter.ts 一个文件 ⇒ SKILL 域表 domain:cli 行明确列有 packages/plugins/plugin-hono-server。不是 domain:devx(它管门禁脚本,而本单不改 scripts/check-route-envelope.mjs),也不是 domain:services。

过时前提检查(git fetch origin main 后逐处核)

正文引用的两处在 origin/main 一字未改,前提成立:

• adapter.ts:365 — }).catch((_err) => {,参数名确为下划线前缀的显式丢弃;
• adapter.ts:165 — return response ?? c.json({ error: 'No response from handler' }, 500);

该文件 origin/main 上最近一次改动是 5e3c83b(lint barrel 可达性,#5648/#5735),未触及这两处。

查重(三仓 open issue + PR)

搜 plugin-hono-server / No response from handler / 适配器吞抛出:无 open 重复单。#4264 已 closed,正文自陈的「不是重复」成立并已核实 —— 它的修法是给三条 datasource 路由各加 catch,接缝本身没动;scripts/check-route-envelope.mjs 结构上看不到未捕获抛出(它审计响应写点)。同族已关单 #4018 / #4073 / #5400 / #3369 均为 discovery / 路由可达性,与本单不同题。

⚠️ 派发范围(接手座位请照此界定)

正文明确把问题分成两半,只有前半入本单:

• ✅ 补日志(本单范围) —— 纯增益、零风险、不改线上响应形状。⚠️ 实现坑正文已点名:Error 的 message/stack 是 non-enumerable,直接塞进结构化 meta 会序列化成 {}(cloud objectos-runtime/src/safe-log.ts 头注释记全了这个坑);
• ⛔ 兜底 body 收成声明信封(不在本单) —— 会改线上响应形状,属公共契约拍板。要做请单独立单走 needs-user-decision,⛔ 不做本单 rider;两件事捆一起会让一个零风险修复卡在一个待裁决问题后面。

证据强度

正文自评「强(main 上代码直读,无需复现环境)」—— 本轮直读 origin/main 复核通过,该自评成立。动机侧有生产证据:cloud 控制面出现过裸 5xx 且日志无痕,cloud#1144 只能在自己路由里逐条 try/catch 补,那是在替这个接缝还债。

本评论来自分诊座位 Routine(#5474 试点),不构成认领。

---

Generated by Claude Code