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

现在基本可以确定问题位置了。

你的数据库信息非常关键：

doc_type        | 
doc_metadata    | null
doc_form        | text_model
word_count      | 12

尤其：

doc_type = 空
doc_metadata = null
word_count = 12

这说明：

Dify 从 WebDAV 下载后，没有识别成 docx 文件。

正常 docx 应该至少有：

doc_type = docx
doc_metadata = {...}
word_count = 几百/几千

更关键的是 pipeline 日志

你的：

datasource_type:
online_drive

输入：

{
 "id": "/Rulr运维/研-儒来平台国产化部署项目说明文档.docx",
 "name": "研-儒来平台国产化部署项目说明文档.docx",
 "bucket": "webdav"
}

说明：

WebDAV 插件只告诉 Dify：

文件在哪里

但是没有告诉 Dify：

这是一个 docx 文件，并提供可解析的文件对象

所以 pipeline 直接进入：

online_drive
    ↓
download
    ↓
text_model
    ↓
general_chunker
    ↓
1 chunk

现在重点查 file_id

你的 documents 表还有：

file_id | text

但是刚才查询没有显示。

执行：

select
id,
file_id,
name
from documents
where id='4e9e360a-5ab3-4957-8de9-75b76e173bdb';

我预计：

情况1（最可能）

结果：

file_id | NULL

那么说明：

WebDAV插件没有把文件保存到 Dify storage。

情况2

有 file_id：

例如：

file_id
--------
xxxx-xxxx

那么继续查：

select *
from upload_files
where id='file_id';

另外查 segments

现在已经知道它只有12字符，再确认一下：

select
id,
position,
content
from document_segments
where document_id='4e9e360a-5ab3-4957-8de9-75b76e173bdb';

我预计：

类似：

position | content
---------+-------
1        | 研-儒来平台国产化部署项目说明文档.docx

如果是这个，就100%确认。

根因定位

你的环境：

Dify 1.15.0
plugin_daemon 0.6.3
shaba/webdav

问题不在 Dify 分段参数。

因为：

第一次：

max_chunk_length=800

第二次：

max_chunk_length=1024

第三次：

max_chunk_length=1024

结果一直：

1 paragraph

说明：

chunker工作正常，只是输入文本只有12字符。

修复方向

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

需要检查：

插件：

shaba/webdav

里的：

online_drive_download_file

这个接口。

它现在应该类似返回：

{
 "type":"file",
 "url":"..."
}

但是 Dify datasource plugin 标准应该返回：

文件二进制流 + 文件名 + mime。

需要保证：

filename:
研-儒来平台国产化部署项目说明文档.docx

mime:
application/vnd.openxmlformats-officedocument.wordprocessingml.document

方案B：不用 datasource，改同步上传

如果只是想把 WebDAV 当文件仓库：

可以：

WebDAV
 ↓
rclone sync
 ↓
本地目录
 ↓
Dify API上传

这样一定走：

upload_file
docx parser
chunk

方案C：检查插件版本

进入 plugin 容器：

docker exec -it docker-plugin_daemon-1 bash

查看安装插件：

ls /app/plugins

确认：

shaba/webdav

版本。

可能需要升级。

现在请再执行两个命令：

1.

select
id,
file_id,
name
from documents
where id='4e9e360a-5ab3-4957-8de9-75b76e173bdb';

2.

select
position,
content
from document_segments
where document_id='4e9e360a-5ab3-4957-8de9-75b76e173bdb';

这两个结果出来后，可以确定是 插件返回文件问题 还是 下载文件内容问题。目前已经非常接近根因。

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

不是 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 字段结构，然后给你准确的关联修复方案。

现在可以下最终结论了。

你的数据链路如下：

upload_files
        |
        |  正常
        ↓
f20a94e5-19b2-4219-b991-5abbc3ea0627
研-儒来平台国产化部署项目说明文档.docx
size=2847874
mime_type=docx
key=upload_files/...docx


documents
        |
        | 断了
        ↓
4e9e360a-5ab3-4957-8de9-75b76e173bdb
file_id=NULL

所以：

文件已经存在，但 document 没有关联文件。

这就是为什么：

word_count = 12
paragraph = 1
doc_type = NULL

因为 Dify 没走 docx parser，而是把 datasource metadata 当文本处理了。

先做一次手工修复验证

建议先不要改插件，验证关联是否能解决。

1. 备份当前 document

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

2. 写入 file_id

执行：

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

确认：

select
id,
name,
file_id
from documents
where id='4e9e360a-5ab3-4957-8de9-75b76e173bdb';

应该：

id                                   file_id
---------------------------------------------------
4e9e360a...                          f20a94e5...

但是注意

仅修改 file_id 可能还不够。

因为你的 document 已经生成过错误 segment：

检查：

select
count(*)
from document_segments
where document_id='4e9e360a-5ab3-4957-8de9-75b76e173bdb';

如果 >0：

需要删除旧分段：

delete from document_segments
where document_id='4e9e360a-5ab3-4957-8de9-75b76e173bdb';

然后重新触发分段。

为什么 WebDAV 会出现这个问题？

从你的日志：

POST /dispatch/datasource/online_drive_download_file
HTTP 200

说明插件下载成功。

但是后续：

general_chunker
Outputs:
["online_drive"]

这里说明 pipeline 收到的是：

online_drive文本

不是：

docx文件

正常流程应该：

WebDAV
 |
download_file
 |
upload_files
 |
file_id
 |
document.file_id
 |
docx parser
 |
chunk
 |
embedding

你的实际：

WebDAV
 |
download_file
 |
upload_files     ✅
 |
document        ❌ file_id丢失
 |
general_chunker
 |
1段

长期修复点

应该改：

shaba/webdav

插件。

重点看：

online_drive_download_file

返回结构。

它现在应该没有返回：

{
  "file_id": "f20a94e5-19b2-4219-b991-5abbc3ea0627"
}

或者没有触发 document 创建时绑定。

建议下一步

先执行手工：

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

然后在 Dify 界面点：

知识库
→ 文档
→ 重新索引

看：

文档信息

是否变成：

doc_type: docx
word_count: xxxx
段落数量: xx

如果成功，就可以确定 100% 是 WebDAV 插件的 file_id 绑定 bug。

下一步再改插件，不需要继续排查 Dify 核心。

很好，现在验证环境已经准备好了。

当前状态：

✅ documents.file_id 已补上：

4e9e360a-5ab3-4957-8de9-75b76e173bdb
        |
        |
        v
f20a94e5-19b2-4219-b991-5abbc3ea0627

✅ 错误生成的 segment 已删除：

document_segments = 0

下一步不要直接重新创建 segment，建议先检查 document 状态字段，否则 Dify 可能认为已经处理完成。

1. 查看当前 document 状态

执行：

select
id,
word_count,
tokens,
doc_type,
indexing_status,
parsing_completed_at,
splitting_completed_at,
completed_at,
error
from documents
where id='4e9e360a-5ab3-4957-8de9-75b76e173bdb';

重点看：

indexing_status
splitting_completed_at
completed_at

2. 重置处理状态

如果现在类似：

indexing_status = completed
splitting_completed_at 有值
completed_at 有值

需要清掉：

执行：

update documents
set
word_count=null,
tokens=null,
parsing_completed_at=null,
cleaning_completed_at=null,
splitting_completed_at=null,
completed_at=null,
indexing_status='waiting',
error=null
where id='4e9e360a-5ab3-4957-8de9-75b76e173bdb';

3. 重新触发索引

推荐优先用 UI：

知识库
 → 文档
 → 研-儒来平台国产化部署项目说明文档.docx
 → 重新索引

观察 worker：

docker logs -f docker-worker-1

正常应该看到：

类似：

parse document
loader: docx
extract text
split document
generate segments
embedding xxx texts

而不是：

general_chunker
online_drive
1 texts

4. 验证结果

重新完成后：

documents

select
name,
word_count,
doc_type,
tokens
from documents
where id='4e9e360a-5ab3-4957-8de9-75b76e173bdb';

期待：

类似：

name                                  word_count doc_type tokens
---------------------------------------------------------------
研-儒来平台国产化部署项目说明文档.docx  5000       docx     xxxx

segments

select
count(*)
from document_segments
where document_id='4e9e360a-5ab3-4957-8de9-75b76e173bdb';

期待：

几十 / 上百