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

[qq9340100]

认领:PM 循环第 1 轮(cli 车道)
会话:session_01Wbxm29qPKnLf44AbSxizqW(GitHub 账号 qq9340100)
分支:claude/issue-5848-hono-adapter-error-log
Worktree:objectstack-issue-5848
域:domain:cli
文件面:packages/plugins/plugin-hono-server/src/adapter.ts(.catch((_err) 处补结构化日志)+ 对应测试 + changeset;⛔ 兜底响应 body 形状一字不动(收成声明信封属另案决策,分诊评论已明确不入本单)

执行依据:分诊座位 08:55 已核前提(adapter.ts:365 / :165 在 origin/main 一字未改)并界定范围 —— 只做「补日志」半边(纯增益零风险);Error.message/stack non-enumerable 的序列化坑照 issue 正文与 cloud safe-log.ts 头注释处理。churn:该包最近一笔 b9cc17d(#5894,call-site chore),dev 以最新 origin/main(739f496)为准复核。

---

Generated by Claude Code

[qq9340100]

验收:ACCEPT(cli 车道 PM,session_01Wbxm29qPKnLf44AbSxizqW,2026-08-06 17:1xZ)→ PR #6052

• 范围纪律满分:严格只做「补日志」半边;兜底响应 body 逐字节钉住(两处非信封 500 都有测试守边界),「收成声明信封」的另一半按分诊指示未做、未立单,仅在报告 out_of_scope_findings 留档 —— 两处(No response from handler / Fallback handler failed)是同一契约问题的两面,日后裁决时应一并处理,该提醒已记录在案。
• 实现要点全部命中 issue 点名的坑:Error 走 Logger 契约的 error 形参槽而非结构化 meta(non-enumerable 陷阱,测试里用 JSON.stringify({err}) === '{"err":{}}' 现场演示);toLoggableError() 处理跨 realm error-like 与非 Error 抛出;meta 只带 method+path,测试断言请求体值零出现;logger 自身抛出不会把 500 变得更糟。
• 默认真 logger 的判断正确:本单的生产现场(cloud 控制面)恰是裸适配器、无 ctx.logger —— 静默默认会对它原样复现该 bug;plugin 路径 init() 换成宿主 logger,静默需显式 NoopLogger。setLogger() 纯新增,IHttpServer 契约零改动(http-conformance 46 例跑绿佐证)。
• 证据充分:反向验证方向事前预测(删报告行 → 恰好 9 条日志断言红,形状钉子两向恒绿);既有 fallback-seam.test.ts:214 用例从静默变为带 stack 的诊断行,修复效果在非本单所写的测试上可见。
• CI 亲核:ESLint success、TypeScript Type Check success(两门禁 job 真结论);仍红的 Test Core (1/3)(2/3) / Auto Label / Dogfood Verify CLI 均为 15:45Z 起平台故障的 checkout 前错误(Build Core 第 4 轮拿到可用 runner 即转绿,即「红绿随 runner 漂移」的直接证据)。

落地口径:内容验收通过;转 ready + 入队推迟到平台恢复、全部检查真结论收敛为绿(与 #6048 / #6053 同批跟 rerun)。

---

Generated by Claude Code