Skip to main content

Dify Webdav上传文件不能分段分析处理过程记录

这个结果非常关键，前面的判断需要修正一下：

不是 WebDAV 没有上传文件。

因为 upload_files 里已经有：

研-儒来平台国产化部署项目说明文档.docx
extension = docx
mime_type = application/vnd.openxmlformats-officedocument.wordprocessingml.document

说明：

✅ WebDAV 下载文件成功
✅ 文件类型识别正常
✅ upload_files 已生成文件记录

但是：

documents.file_id = NULL

说明：

文件已经上传到 storage，但知识库 document 没有关联这个 file_id。

这就是导致：

doc_type = NULL
doc_metadata = NULL
word_count = 12
1 paragraph

的直接原因。

现在需要查关联关系

Dify 1.15 这里通常通过：

documents.file_id
        ↓
upload_files.id

关联。

你的异常：

documents
 id:
4e9e360a-5ab3-4957-8de9-75b76e173bdb

file_id:
空

但是 upload_files 有：

9dc4b86e-7f4c-4804-a5a8-f81742148ddc

这两个没有连起来。

找对应的 upload_file

执行：

select
id,
name,
extension,
created_at
from upload_files
where name='研-儒来平台国产化部署项目说明文档.docx'
order by created_at desc;

你会看到多个。

注意时间：

你的 document：

created_at:
2026-07-09 07:31:48

但是 upload_files：

例如：

2026-07-09 02:40:27

这里有时区差：

PostgreSQL显示 UTC，本地显示 +8。

大概率对应：

9b2f7c06-e091-4332-a3e9-83c84af21bb8

或者：

b69aa5e5-f81d-447f-a13f-8b106c03f5f4

验证一下

执行：

select
d.id as document_id,
d.name,
d.file_id,
u.id as upload_id,
u.name as upload_name
from documents d
left join upload_files u
on d.file_id=u.id
where d.name='研-儒来平台国产化部署项目说明文档.docx';

现在应该显示：

document_id                         file_id upload_id
----------------------------------------------------
4e9e360a...                         NULL    NULL

根因已经变成：

不是：

❌ WebDAV插件不能下载文件

而是：

❌ WebDAV datasource pipeline 创建 document 时，没有把 upload_file_id 写入 documents.file_id

为什么本地上传正常？

本地：

upload_files
    |
    |
documents.file_id
    |
docx parser

WebDAV：

upload_files
    |
    X
documents.file_id=NULL
    |
text_model

修复方案

方案1：修 shaba/webdav 插件（推荐）

检查插件代码：

online_drive_download_file

它应该返回：

类似：

{
 "file_id":"9dc4b86e-7f4c-4804-a5a8-f81742148ddc"
}

现在返回可能只有：

{
 "id":"/Rulr运维/xxx.docx",
 "name":"xxx.docx",
 "bucket":"webdav"
}

方案2：手工验证（不要长期用）

可以直接更新：

update documents
set file_id='对应upload_files.id'
where id='4e9e360a-5ab3-4957-8de9-75b76e173bdb';

然后重新分段。

如果马上恢复：

说明100%就是关联问题。

⚠️ 建议先备份数据库。

还有一个需要查的表

Dify 1.15 datasource 可能还记录文件绑定：

执行：

select *
from segment_attachment_bindings
where document_id='4e9e360a-5ab3-4957-8de9-75b76e173bdb';

不过目前不是重点。

现在请执行：

select
id,
name,
created_at
from upload_files
where name='研-儒来平台国产化部署项目说明文档.docx'
order by created_at desc;

然后把结果贴一下。

我们找出和这个 document 对应的 upload_file_id，做一次手工关联测试，就能最终确认。

这个错误也很有价值：

ERROR: operator does not exist: text = uuid
LINE 9: on d.file_id=u.id

说明：

documents.file_id  类型 = text
upload_files.id    类型 = uuid

所以 PostgreSQL 不会自动比较，需要转换类型。

执行：

select
d.id as document_id,
d.name,
d.file_id,
u.id as upload_id,
u.name as upload_name
from documents d
left join upload_files u
on d.file_id = u.id::text
where d.name='研-儒来平台国产化部署项目说明文档.docx';

不过根据你前面的结果：

documents.file_id = 空

大概率结果还是：

document_id                         file_id   upload_id
-------------------------------------------------------
4e9e360a-5ab3-4957-8de9-75b76e173bdb NULL      NULL

下一步我们需要找对应的 upload_file

你的 WebDAV 重试产生了 5 个同名文件：

2026-07-09 01:40:07
2026-07-09 02:20:31
2026-07-09 02:27:43
2026-07-09 02:40:27
2026-07-09 02:49:38

对应你的 document：

documents.created_at
2026-07-09 07:31:48

这里有时区 +8：

Postgres:

2026-07-09 07:31:48

实际北京时间：

2026-07-09 15:31:48

而 upload_files：

2026-07-09 02:49:38 UTC

北京时间：

2026-07-09 10:49:38

不完全对应。

所以还需要查 pipeline 日志里的创建时间：

document_pipeline_execution_logs
created_at
2026-07-09 07:31:48

对应 upload_file 可能是：

f20a94e5-19b2-4219-b991-5abbc3ea0627

但不要直接改，先验证。

验证 upload_file 内容

查：

select
id,
name,
key,
size,
extension,
mime_type
from upload_files
where id='f20a94e5-19b2-4219-b991-5abbc3ea0627';

如果有：

key
bucket
size

说明是真文件。

然后做一个临时修复测试

先备份：

create table documents_backup as
select * from documents
where id='4e9e360a-5ab3-4957-8de9-75b76e173bdb';

然后：

update documents
set file_id='f20a94e5-19b2-4219-b991-5abbc3ea0627'
where id='4e9e360a-5ab3-4957-8de9-75b76e173bdb';

重新执行知识库：

  • 删除当前分段

  • 重新分段

如果：

word_count
从 12
变成几千

paragraphs
从 1
变几十/几百

那么根因完全确认。

不过还有一个可能性：

你的日志里：

POST plugin_daemon dispatch/tool/invoke
Tool: general_chunker

Outputs:
{
 "variable_value":["online_drive"]
}

这里很异常。

正常应该：

docx parser
    ↓
text
    ↓
general_chunker

现在像是：

online_drive
    ↓
general_chunker

也就是说 WebDAV datasource 没有触发文件解析节点。

所以最终修复点大概率还是：

shaba/webdav 插件的数据源返回结构。

你先跑上面的：

select
id,
name,
key,
size,
extension,
mime_type
from upload_files
where id='f20a94e5-19b2-4219-b991-5abbc3ea0627';

以及：

\d upload_files

我需要确认 Dify 1.15 的 upload_files 字段结构，然后给你准确的关联修复方案。

Back to top