[Web GUI] 开启微信输入法「跨设备复制粘贴」后,粘贴图片无法发送:"A requested file or directory could not be found at the time an operation was processed."

[young1lin]

TL;DR (EN): With the WeChat input method's cross-device clipboard sync enabled on Windows, pasting an image into the dsh web composer often fails to send, with a toast reading "A requested file or directory could not be found at the time an operation was processed." The string is produced nowhere in the harness — it is Chromium's DOMException [NotFoundError] from FileReader.readAsDataURL() failing on the pasted File, which the composer keeps lazily and only reads at submit time.

环境

• dsh 0.1.5-rc.1,Web GUI(Chrome/Edge 内核浏览器),Windows 11
• 微信输入法,开启了「跨设备复制粘贴」(剪贴板同步) （图片被截了，但是还是能粘贴成功，网页上能看到对应的图片已经粘上去了）
• 模型侧:OpenAI Codex 订阅模型(gpt-5.x / gpt-6-astra,经 dsh-llm-pi-ai 的 openai-codex 协议)与 GLM-5.3-flash(zai,原生多模态)

症状

粘贴图片后点发送,消息发不出去,composer 弹 toast:

A requested file or directory could not be found at the time an operation was processed.

表面上看和模型强相关:用 Codex 订阅模型基本必现,用 GLM-5.3-flash 一切正常——所以一开始完全查错了方向。

排查(这条文案到底是谁产生的)

1. 怀疑是 Node fs.cp 的 ERR_FS_CP_ENOENT → 排除:Node 的 fs.cp 错误码表里没有这个码,实测缺源文件报的是普通 ENOENT ... lstat。

2. 对 harness 仓库源码、已安装的全局 dsh bundle、已装载的 web client bundle、本地自定义插件源码、request-log、以及解压后的最近 session 日志做全文检索 → 这句话在本地任何地方都不存在。

3. 检索该句原文 → 它是 Chromium 的固定文案,见 third_party/blink/renderer/core/fileapi/file_error.cc:

   const char kNotFoundErrorMessage[] =
       "A requested file or directory could not be found at the time an "
       "operation was processed.";

   即 blink 文件 API 的 kNotFoundError → DOMException [NotFoundError] 消息;OPFS、File System Access、FileReader 等失败时都会抛出。

根因链路(以当前 master 源码行号为准;已装 0.1.5-rc.1 的 client bundle 为同一模式)

粘贴
  → keymap.ts PASTE_COMMAND → item.getAsFile()
    (packages/client/ui-conversation/src/client/input/editor/keymap.ts:137)
  → createDrafts → browserDraftAttachment(file)
    (service.ts:73) 只建了 URL.createObjectURL 预览,字节未读,
     浏览器 File 对象被原样存进 draftAttachments

发送(两条提交路径同样行为)
  → sendSession → serializeAttachments → encodeImage(attachment.file)
    (service.ts:260)
  → serializeDraftAttachments → encodeImage(attachment.file)
    (service.ts:454)
  → base64ImageOf(file) → FileReader.readAsDataURL(file)
    (service.ts:124-135,reader.onerror 直接 reject reader.error)
  → 粘贴与发送之间,剪贴板同步功能接管了剪贴板,
    File 背后的快照失效 → DOMException [NotFoundError]
  → submission.abandon() → facade notify('error', error.message)
    (facade.ts:378) → InputBar toast(InputBar.tsx:111)
     文案 = DOMException.message,一字不差

关键点:图片草稿被惰性持有,直到提交才第一次读字节。对比之下,非图片文件草稿在 intake 时就后台上传(beginFileUpload),不受影响——所以只有贴图踩坑。

[PerryLink]

根因链在 master（c291e7961）确认属实，且 bug 仍在（你的行号基本吻合，个别差几行，以 master 为准）：

• 粘贴入口只拿 File 快照：PASTE_COMMAND → clipboardData.items → getAsFile() → intakeFiles（ui-conversation/src/client/input/editor/keymap.ts:146-154）。
• 图片是惰性持有：browserDraftAttachment 只存 File + objectURL 预览（service.ts:73-80），提交时才读字节；对比文件类附件是立即后台上传（:308-324，图片走 :310-314、文件走 :322）。
• 提交路径：serializeAttachments → encodeImage → base64ImageOf（service.ts:575-581、:124-135，FileReader.readAsDataURL、onerror reject）→ 剪贴板同步使 File 失效 → NotFoundError → abandon()（:286-291）→ UI notify('error')（facade.ts:379/383）。

修复方向（与你的想法一致，更具体）：在 browserDraftAttachment 入口就 await file.arrayBuffer() 把字节固化成 Blob 副本，previewUrl 指向副本——一次改动同时解决提交失败，还能顺带简化 probeDimensions（:90-98）对原 File 的依赖。备选的"提交失败重试"较弱：File 已失效时重试大概率还是 NotFound。

微信输入法"跨设备复制粘贴"失效原 File 的具体时机属于输入法/OS 行为，我未在 Windows 实测（未验证）；临时规避：粘贴后立即点发送，或改用拖拽/文件选择（走立即上传路径）。这个修复小而自包含，适合直接提 PR。