[BUG]: LanceDB commit conflict kills the docker instance

问题场景

用户在 Docker 本地部署的 AnythingLLM 中，通过 UI 或 API 删除多个文件夹中的多个文档时，Docker 实例因未捕获异常而直接退出。后续报告者补充：即使一次只删除一个文档，也偶发同样崩溃，且是在单文件夹内文档数较多（约 300 个、复现步骤建议 100+）的场景下。

报错原文

node:internal/process/promises:288
            triggerUncaughtException(err, true /* fromPromise */);
            ^

[Error: lance error: Commit conflict for version 1993: There was a concurrent commit that conflicts with this one and it cannot be automatically resolved. Please rerun the operation off the latest version of the table.
 Transaction: Transaction { read_version: 1992, uuid: "63c3c1bb-3196-40be-9732-16d584ee73d6", operation: Delete { updated_fragments: [], deleted_fragment_ids: [383], predicate: "id IN ('9c8ab1ce-25d8-4c32-9a47-5d11902edc8a','2d108d54-5bdc-436e-903f-e7643ba39563')" }, blobs_op: None
, tag: None }
 Conflicting Transaction: Some(Transaction { read_version: 1992, uuid: "d8026f8f-ac03-4d94-b579-b956a6c4ce76", operation: Delete { updated_fragments: [], deleted_fragment_ids: [383], predicate: "id IN ('9c8ab1ce-25d8-4c32-9a47-5d11902edc8a','2d108d54-5bdc-436e-903f-e7643ba39563')"
}, blobs_op: None, tag: None }), /home/build_user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/lance-0.22.0/src/io/commit.rs:149:23
Caused by: Commit conflict for version 1993: There was a concurrent commit that conflicts with this one and it cannot be automatically resolved. Please rerun the operation off the latest version of the table.
   Transaction: Transaction { read_version: 1992, uuid: "63c3c1bb-3196-40be-9732-16d584ee73d6", operation: Delete { updated_fragments: [], deleted_fragment_ids: [383], predicate: "id IN ('9c8ab1ce-25d8-4c32-9a47-5d11902edc8a','2d108d54-5bdc-436e-903f-e7643ba39563')" }, blobs_op: None, tag: None }
   Conflicting Transaction: Some(Transaction { read_version: 1992, uuid: "d8026f8f-ac03-4d94-b579-b956a6c4ce76", operation: Delete { updated_fragments: [], deleted_fragment_ids: [383], predicate: "id IN ('9c8ab1ce-25d8-4c32-9a47-5d11902edc8a','2d108d54-5bdc-436e-903f-e7643ba39563')" }, blobs_op: None, tag: None }), /home/build_user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/lance-0.22.0/src/io/commit.rs:149:23
    Caused by: There was a concurrent commit that conflicts with this one and it cannot be automatically resolved. Please rerun the operation off the latest version of the table.
     Transaction: Transaction { read_version: 1992, uuid: "63c3c1bb-3196-40be-9732-16d584ee73d6", operation: Delete { updated_fragments: [], deleted_fragment_ids: [383], predicate: "id IN ('9c8ab1ce-25d8-4c32-9a47-5d11902edc8a','2d108d54-5bdc-436e-903f-e7643ba39563')" }, blobs_op:
None, tag: None }
     Conflicting Transaction: Some(Transaction { read_version: 1992, uuid: "d8026f8f-ac03-4d94-b579-b956a6c4ce76", operation: Delete { updated_fragments: [], deleted_fragment_ids: [383], predicate: "id IN ('9c8ab1ce-25d8-4c32-9a47-5d11902edc8a','2d108d54-5bdc-436e-903f-e7643ba39563')" }, blobs_op: None, tag: None })] {
  code: 'GenericFailure'
}

原因分析

最直接的原因是 LanceDB 表上出现了并发提交冲突：两个事务读取了同一版本（read_version 相同），并试图对同一批 fragment 提交相互冲突的 Delete 操作，LanceDB 无法自动合并，于是抛出 Commit conflict；而该异常未被上层捕获，最终触发 Node.js 的 triggerUncaughtException，导致容器进程以退出码 1 结束。可能的诱因包括：

• 批量删除时多个删除请求/多个文件夹的删除操作并发写入同一张 Lance 表。
• 补充报告者观察到冲突事务针对同一个文档 ID，但事务 UUID 不同，因此可能是文档删除代码路径内部的多个阶段（向量库删除、关系库删除、向量追踪删除）之间发生竞争，或与后台任务竞争，而非单纯的客户端并发。

需要说明的是，维护者未能复现，上述归属中“内部多阶段竞争”属于补充报告者的推断，尚未被确认。

环境排查

• AnythingLLM 部署方式：确认是否为 Docker 本地部署（Issue 报告为 Docker local）。
• Docker 镜像版本：确认使用的 tag（补充报告为 mintplexlabs/anythingllm:latest）。
• 宿主系统：Issue 中报告为 Debian 12.8；另有用户在 mac、Ubuntu/Docker 下正常批量删除。
• 资源规模：CPU/内存/SSD（报告为 8 CPU、192GB RAM、SSD），以及单文件夹/多文件夹的文档数量（补充报告约 300，复现建议 100+）。
• 触发入口：是 UI 批量删除，还是 API（POST /api/v1/workspace/{slug}/update-embeddings 带 deletes，随后 DELETE /api/v1/system/remove-documents）。
• 是否同时存在其他写入 LanceDB 的任务（上传/嵌入/再嵌入等），可能加剧并发。
• Issue 未提供 Python、CUDA、显卡、PyTorch、节点版本等信息，暂不需要作为排查项。

解决步骤

1. 先复现并记录崩溃前的删除方式：是 UI 批量删除还是 API 调用；若是 API，记录是否同时并发调用了 update-embeddings 与 system/remove-documents。
2. 降低删除并发：改为一次只删除一个文档，避免同时对多个文件夹或同一文件夹内多个文档发起删除。
3. 在每次删除之间加入延迟（补充报告者曾以 2s 间隔逐条删除，仍偶发崩溃），观察崩溃是否出现在前几十次删除之内，以判断是否仍存在内部竞争。
4. 若正在通过脚本调用 API，检查是否对同一文档 ID 重复提交了删除请求；确保先调用 update-embeddings 的 deletes，再调用 system/remove-documents，且不要并行发起。
5. 容器退出后查看 docker ps -a 是否显示 Exited (1)，并重启容器；同时保留完整日志中的 Lance 事务与 conflicting transaction 信息，用于进一步定位。
6. 若问题持续且可稳定复现，按 Issue 关闭状态（needs info / can’t replicate）整理完整的复现条件（文档数量、删除入口、调用频率、宿主系统与镜像 tag）后再向项目反馈。

验证方法

在调整删除方式后重复执行同一批删除操作，观察后端日志中是否仍出现 Commit conflict；同时用 docker ps -a 确认容器不再出现 Exited (1)，服务能持续运行而无需手动重启。若在逐条、加延迟的删除下仍复现，说明规避手段无效，需要等待上游修复。

参考来源

Mintplex-Labs/anything-llm #3991

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。