present.open 返回 500：单个文件关联 handler 失败即让整个「打开方式」列表失效，且无任何日志

[ZackZhaii]

按 CONTRIBUTING 指引，在 Discussions 里报告一个 bug。

Summary

在 Windows 桌面端点击"交付文件卡片"打开文件时，前端收到 HTTP 500，文件无法打开；但用 action=open 的 POST 直接打开是成功的。

根因链路：

1. 前端在打开前先请求 GET /api/present.open 去枚举该文件的"可用程序"；
2. 该步最终调用 dsh-native-command 的 List()（PowerShell + C# 适配器调 SHAssocEnumHandlers）；
3. 当枚举结果中存在任意一个注册不规范/指向已不存在路径的第三方 handler 时，对该 handler 调 IHandler.GetName() 会返回 COMException: HRESULT E_FAIL；
4. List() 遍历 handler 时没有逐项容错，一处失败使整个调用抛出；
5. workspacePathApplications 把异常包成 RemoteError("gateway/internal")；
6. handlePresentOpen 的 failureStatus() 不认识该 code，折叠为 500，响应体恒为字符串 Presented file unavailable.，且 catch 不记录任何日志。

影响：任何安装了"注册信息已失效"的第三方软件的 Windows 用户，都会完全无法通过 UI 打开文件卡片，且无法自助定位原因。

Reproduction

最小可复现条件：该系统上存在一个 handler，其注册表指向的文件已不存在。

1. 准备一台 Windows，安装任意会在 HKCU\Software\Classes\Applications\<App>.exe\shell\open\command 注册、随后被移动或卸载的程序（本机案例：Cursor 从 C:\Users\...\AppData\Local\Programs\cursor 移到 D:\ZACK\cursor，旧路径残留）；
2. 确认该 handler 已被 SHAssocEnumHandlers 枚举到（同一扩展名下其他 handler 正常）；
3. 在 DSH 桌面端点击任一"交付文件卡片"；
4. 观察 DevTools Network：dsh-app://app/api/present.open?sessionId=…&seq=…&index=0 → 500。

对照实验（用于区分"枚举"与"打开"两条分支）：

GET  /api/present.open?sessionId=<sid>&seq=<seq>&index=0              -> 500
GET  /api/present.open?sessionId=<sid>&seq=<seq>&index=99             -> 404（说明事件读取与文件选择都正常）
POST /api/present.open?sessionId=<sid>&seq=<seq>&index=0&action=open   -> 204（打开本身成功）
POST /api/present.open?sessionId=<sid>&seq=<seq>&index=0&action=reveal -> 204（定位本身成功）

Current behavior

• GET 分支返回 500，body 恒为 Presented file unavailable.
• 无任何日志：handlePresentOpen 的 catch 既不打 console.error 也不附 cause，--enable-logging 同样抓不到
• List() 内单点失败导致整个列表作废；workspacePathApplications 也没有降级路径
• 用户侧表现为"点卡片打不开文件"，与"文件不存在""坐标过期"等现象无法区分

逐步插桩的实际输出（对 List() 内各步骤单独 try/catch）：

extension=.md
1 Associated(EXECUTABLE) OK -> <null>
2 Associated(APPID)      OK -> Anysphere.Cursor
3 SHAssocEnumHandlers    OK -> instance
4 Next()                 hr=0x00000000 fetched=1
5 GetName                THREW COMException: 对 COM 组件的调用返回了错误 HRESULT E_FAIL。
6 GetUIName              THREW COMException: 对 COM 组件的调用返回了错误 HRESULT E_FAIL。
7 GetIconLocation        OK -> C:\...\Programs\cursor\Cursor.exe idx=0
9 List()                 THREW COMException: ...

注意：SHAssocEnumHandlers 与 Next() 均成功，失败仅发生在单个 handler 的 GetName / GetUIName。

同机其他 handler（记事本、Acrobat、Chrome、Edge、Figma 等）GetName 全部正常，说明接口约定本身没问题，是个别第三方注册不规范。

修复该 handler 的注册路径后：

handler[0] GetName OK id='D:\ZACK\cursor\Cursor.exe' ui='Cursor'
nativeFileApplications() ✅ 18 个应用
GET  /api/present.open  -> 200

Expected behavior

建议（按投入从低到高）：

1. List() 逐 handler 容错：GetName / GetUIName 抛错时跳过该 handler（或退化用 GetIconLocation 的路径作 id），不中断整个枚举。这是最小修复，且与"某个应用图标取不到不应让整个列表失败"的既有注释风格一致（PngFromIconSource 已经这样处理了图标）。
2. workspacePathApplications 降级：枚举失败时返回空列表（200 []），让前端退化为"直接用默认程序打开"，而不是 500。
3. 补日志：handlePresentOpen 的 catch 至少 console.error(name/code/message/cause)，否则此类问题只能靠外部复现。
4. 保留错误语义：500 的响应体建议附一个 diagnostic id 或原始 code，便于用户报障时对齐日志。

附带的观察：当前 400 / 404 / 409 / 422 的语义划分是清晰的（坐标非法 / 事件或文件找不到 / 桌面桥不可用 / 路径映射失败），这一层设计没问题；问题集中在"枚举分支没有降级"和"catch 不可观测"。

Environment

项	值
DSH	0.2.1-rc.2（桌面端，app.asar 内 @deepseek-ai/dsh 同为 0.2.1-rc.2）
形态	Electron 桌面端，页面走自定义协议 dsh-app://app/
Electron / Node	44.7.0 / 24.21.0
OS	Windows 10 专业版 19045（AMD64）
PowerShell	5.1.19041.6456（-STA，脚本由 DSH 生成）
相关包	@deepseek-ai/dsh-native-command（List() / windowsFileApplications）、@deepseek-ai/dsh-api-session-controller（workspacePathApplications）、@deepseek-ai/dsh-client-ui-deliverables（handlePresentOpen）
触发环境	第三方应用（本例 Cursor）移动安装目录后，HKCU\Software\Classes 下 6 处关联仍指向已不存在的旧路径

---

本机缓解方式（供其他用户参考，非代码修复）

把失效 handler 的注册表路径改指真实位置即可，无需改 DSH、无需重启：

HKCU\Software\Classes\Applications\<App>.exe\DefaultIcon
HKCU\Software\Classes\Applications\<App>.exe\shell\open (Icon)
HKCU\Software\Classes\Applications\<App>.exe\shell\open\command
HKCU\Software\Classes\<ProgId>\DefaultIcon
HKCU\Software\Classes\<ProgId>\shell\open (Icon)
HKCU\Software\Classes\<ProgId>\shell\open\command

---

[PerryLink]

第 4 步我核到了，而且有个现成的反例就在同一个文件里：这个文件知道 handler 会抛，只是没在那个位置防。

packages/util/native-command/src/file-applications-windows.ts:181-190：

static void Visit(string path, Action<IHandler> visit) {
  var extension = Path.GetExtension(path);
  if (extension.Length == 0) return;
  SHAssocEnumHandlers(extension, 0, out handlers);
  ...
  Marshal.ThrowExceptionForHR(result);

:202-204 的遍历体：

Visit(path, delegate(IHandler handler) {
  handler.GetName(out id); handler.GetUIName(out name);

GetName / GetUIName 一行一个，外面没有任何 try。任一项抛 COMException，整个 Visit 就中止，枚举结果一个都拿不到 —— 和你说的一致。

但同一个文件的 :163-165 是这样的：

static string IconData(IHandler handler, string id) {
  try { handler.GetIconLocation(out source, out index); } catch (Exception) {

图标路径那一步是逐项 catch 的。也就是说这个文件已经承认"某个 handler 的注册信息可能已经坏了"，只是把这份容错用在了取图标上，没用在取名字上。修法就是把 :202-204 包进同样的 try，失败的 handler 跳过、继续下一个；GetName 失败的那一项至多失去显示名，不该让整张列表消失。

关于第 6 步的 500，我没有核那条链（failureStatus() 的折叠和 catch 里的静默），所以只能说你贴的枚举失败这一环成立。

顺带一个可以写进报告的判断依据：E_FAIL 有两个可能的抛出点 —— :190 的 Marshal.ThrowExceptionForHR(result)（枚举本身失败）和 :204 的 GetName（某一项坏）。报告里把异常是从哪一行出来的写清楚，别人复现时才能区分"这台机器没有可用的关联"和"某个第三方注册坏了"，这两种情况的修法不一样。