Knowledge file resources pass docs_* IDs to chunk actions and semantic search

快速结论：该 bug 发生在 LobeChat 知识库（Knowledge Base）的文件资源管理中，当文件同时创建了 files 和 documents 行时，知识库查询返回的 id 字段可能是 docs_* 前缀，但后续切片（chunking）、嵌入重试（embedding retry）和语义搜索（semantic search）接口期望接收的是 file_* 前缀的真实文件 ID。优先排查知识库列表项中 id 和 fileId 的值是否一致。

问题场景

用户使用 LobeChat（Web 桌面端，macOS，Docker 自部署或本地开发环境，Chrome 浏览器，canary 版 d6935cd13050355efd60000d8c18bdf01ab20794），在上传文件到知识库后，进行 重试嵌入（Retry Embedding）、打开切片抽屉（Open Chunks Drawer） 或 语义搜索（Semantic Search） 时，发现操作无响应或返回空结果。

报错原文

// 请求负载示例：使用 docs_* ID 导致语义搜索无结果
{"fileIds":["docs_B2x3zYnRUttCGMvN"],"query":"..."}

// 重试嵌入请求也使用 docs_* ID，可能导致静默无操作
{"id":"docs_Yfov9wsQ8lvLEHlR","type":"embedding"}

原因分析

根本原因： 知识库仓库（Knowledge Repository）的 SQL 查询使用了 COALESCE(d.id, f.id) as id。当文件有对应的 documents 行时，COALESCE 会优先返回 d.id（即 docs_*），导致列表项的 id 字段为 docs_*，而切片和语义搜索路径是按 fileChunks.fileId（即 file_*）过滤的。
具体代码路径：

packages/database/src/repositories/knowledge/index.ts 返回 COALESCE(d.id, f.id) as id，以及 f.id as file_id 和 d.id as document_id。
FileListItemActions.tsx 将 id={id} 传递给 ChunksBadge。
ChunkTag.tsx 使用该 id 调用 embeddingChunks([id])、reParseFile(id)、reEmbeddingChunks(id)、openChunkDrawer(id)。
packages/database/src/models/chunk.ts 的语义搜索按照 fileChunks.fileId 过滤，因此必须传入 file_* ID。

环境排查

LobeChat 版本： canary d6935cd13050355efd60000d8c18bdf01ab20794 及包含此代码的后续版本。
客户端类型： Web（桌面浏览器）。
部署方式： Docker 自部署 / 本地开发。
数据库： 确认知识库表中 files 和 documents 行是否关联存在。

解决步骤

确认 ID 值： 检查知识库列表返回的 JSON，确认 id 是否为 docs_*，而 fileId 是否为 file_*。
优先尝试修复模式（已有社区 PR 先例）： 在用户操作层（如 FileListItemActions.tsx 和 ChunkTag.tsx）中，当调用切片、嵌入重试、切片抽屉、删除/重新解析等与文件/切片相关的 API 时，将 id 替换为 fileId ?? id（即优先使用 fileId）。参考以下已合并的修复 PR 模式：
– PR #14051：修复 docs_* ID 导致代理 URL 生成错误。
– PR #14494：在 readKnowledge 中分支处理 file_* vs docs_*。
– PR #14673：在 KnowledgeBaseSearchService 中显式分支处理 ID 类型。
– PR #15247：修复 BM25 搜索正确处理两种 ID 类型。
服务端防御性处理（可选）： 在服务端 API 中，当接收到 docs_* ID 时，反向解析到关联的 documents.fileId。
自定义修改： 如果你是从源码构建，可以直接修改 src/features/ResourceManager/... 下的逻辑，传入正确的 fileId。