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';

 

 期待： 

 几十 / 上百

 

 而不是： 

 1

 

 

 如果重新索引后恢复，就可以最终确认： 

 shaba/webdav 插件 bug：创建 document 时遗漏 documents.file_id 。 

 之后修插件只需要在 datasource pipeline 创建 document 时补： 

 document.file_id = upload_file.id

 

 即可。 

 你现在先执行第 1 步，把 document 状态贴出来，我确认是否需要 reset。