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

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

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

```text
doc_type        | 
doc_metadata    | null
doc_form        | text_model
word_count      | 12

```

尤其：

```text
doc_type = 空
doc_metadata = null
word_count = 12

```

这说明：

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

正常 docx 应该至少有：

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

```

---

## 更关键的是 pipeline 日志

你的：

```json
datasource_type:
online_drive

```

输入：

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

```

说明：

WebDAV 插件只告诉 Dify：

> 文件在哪里

但是没有告诉 Dify：

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

所以 pipeline 直接进入：

```
online_drive
    ↓
download
    ↓
text_model
    ↓
general_chunker
    ↓
1 chunk

```

---

# 现在重点查 file\_id

你的 documents 表还有：

```text
file_id | text

```

但是刚才查询没有显示。

执行：

```sql
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

```

那么继续查：

```sql
select *
from upload_files
where id='file_id';

```

---

# 另外查 segments

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

```sql
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

```

这个接口。

它现在应该类似返回：

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

```

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

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

需要保证：

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

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

```

---

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

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

可以：

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

```

这样一定走：

```
upload_file
docx parser
chunk

```

---

## 方案C：检查插件版本

进入 plugin 容器：

```bash
docker exec -it docker-plugin_daemon-1 bash

```

查看安装插件：

```bash
ls /app/plugins

```

确认：

```
shaba/webdav

```

版本。

可能需要升级。

---

现在请再执行两个命令：

### 1.

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

```

### 2.

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

```

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

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

**不是 WebDAV 没有上传文件。**

因为 `upload_files` 里已经有：

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

```

说明：

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

但是：

```text
documents.file_id = NULL

```

说明：

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

这就是导致：

```text
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

执行：

```sql
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。

大概率对应：

```text
9b2f7c06-e091-4332-a3e9-83c84af21bb8

```

或者：

```text
b69aa5e5-f81d-447f-a13f-8b106c03f5f4

```

---

## 验证一下

执行：

```sql
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

```

它应该返回：

类似：

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

```

现在返回可能只有：

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

```

---

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

可以直接更新：

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

```

然后重新分段。

如果马上恢复：

说明100%就是关联问题。

⚠️ 建议先备份数据库。

---

## 还有一个需要查的表

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

执行：

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

```

不过目前不是重点。

---

现在请执行：

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

```

然后把结果贴一下。

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

这个错误也很有价值：

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

```

说明：

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

```

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

执行：

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

```

不过根据你前面的结果：

```text
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 可能是：

```text
f20a94e5-19b2-4219-b991-5abbc3ea0627

```

但不要直接改，先验证。

---

## 验证 upload\_file 内容

查：

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

```

如果有：

```
key
bucket
size

```

说明是真文件。

---

## 然后做一个临时修复测试

先备份：

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

```

然后：

```sql
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` 插件的数据源返回结构。

---

你先跑上面的：

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

```

以及：

```sql
\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

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

```

---

### 2. 写入 file\_id

执行：

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

```

确认：

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

```

应该：

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

```

---

## 但是注意

仅修改 `file_id` **可能还不够**。

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

检查：

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

```

如果 >0：

需要删除旧分段：

```sql
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

```

返回结构。

它现在应该没有返回：

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

```

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

---

## 建议下一步

先执行手工：

```sql
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` 已补上：

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

```

✅ 错误生成的 segment 已删除：

```text
document_segments = 0

```

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

---

## 1. 查看当前 document 状态

执行：

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

```

重点看：

```text
indexing_status
splitting_completed_at
completed_at

```

---

## 2. 重置处理状态

如果现在类似：

```text
indexing_status = completed
splitting_completed_at 有值
completed_at 有值

```

需要清掉：

执行：

```sql
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：

```bash
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

```sql
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

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

```

期待：

```
几十 / 上百

```

而不是：

```
1

```

---

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

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

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

```python
document.file_id = upload_file.id

```

即可。

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