[Bug]: entrypoint.sh starts task_executor.py with positional worker ID, causing unrecognized arguments and preventing document parsing

快速结论：该报错通常出现在用 Docker / Docker Compose 启动 RAGFlow 后，文档可以上传、接口也返回成功，但后台文档解析一直不执行；优先排查 entrypoint 启动 task_executor 时是否把 worker ID 作为位置参数传入，而不是用 -i/–index 传入。

适用环境：依据 Issue 记录，环境为 Docker / Docker Compose 部署，容器名 docker-ragflow-cpu-1，运行路径中出现 Python 3.13 的 .venv 包路径（如 /ragflow/.venv/lib/python3.13/site-packages/…），搜索后端为 Elasticsearch（es01:9200），RAGFlow server 端口 9380。RAGFlow 代码 commit 和镜像版本在报告时未采集。操作系统、宿主环境和 CUDA 信息未提供。

最快修复方案：Issue 中维护者表示该问题已被修复并关闭，未给出单条命令级的一步修复方案；可优先尝试更新到包含修复的 RAGFlow 版本或重新拉取修复后的镜像，并确认 entrypoint.sh 不再以位置参数启动 task_executor.py。

注意事项：Issue 未给出具体修复 commit、镜像 tag 或可直接执行的命令，因此不要仅凭本页手动改脚本；如需手动修改，应先备份 entrypoint.sh，并在确认 task_executor.py 仅接受 -i/–index 和 -t/–type 后再调整。若更新后仍出现同样报错，需要在原 Issue 补充新证据或重新打开。

问题场景

用户在 Docker / Docker Compose 中运行 RAGFlow，容器名为 docker-ragflow-cpu-1，服务监听 9380 端口，搜索后端使用 Elasticsearch（es01:9200）。RAGFlow 服务能正常启动，API 可访问，Elasticsearch 返回 HTTP 200，POST /api/v1/documents/ingest 也返回 HTTP 200，但后端文档解析任务没有真正执行，文档解析失败。日志中反复出现 task_executor.py 因收到生成式 worker/index 值而报错。

报错原文

usage: task_executor.py [-h] [-i INDEX] [-t TYPE]
task_executor.py: error: unrecognized arguments: a9f8cd94c703_0

usage: task_executor.py [-h] [-i INDEX] [-t TYPE]
task_executor.py: error: unrecognized arguments: 44b2011eb929_0

usage: task_executor.py [-h] [-i INDEX] [-t TYPE]
task_executor.py: error: unrecognized arguments: 33b141fb3690_0

原因分析

从 Issue 证据看，最可能的原因是启动脚本 docker/entrypoint.sh 在拉起 task_executor.py 时，把类似 a9f8cd94c703_0、44b2011eb929_0、33b141fb3690_0 的 worker/index 值作为裸位置参数传入。而 task_executor.py 的 argparse 只定义了 -i/–index 和 -t/–type 两个可选参数，没有定义位置参数，因此 argparse 判定这些额外的位置参数无法识别并直接退出。

报错值在不同重启中不断变化，说明问题不是某一份文档 ID 损坏，而是生成的主机/消费者 worker ID 被错误地附加到了命令后面。服务端 API 和 Elasticsearch 在此期间多次返回 200，说明它们不是失败组件，失败点集中在任务执行器的启动参数拼接上。

环境排查

确认部署方式是否为 Docker / Docker Compose，容器名是否与 Issue 中一致（docker-ragflow-cpu-1）。
确认 RAGFlow 镜像版本和代码 commit；Issue 报告时这两项未采集，可能导致修复是否已包含无法判断。
确认容器内 Python 版本；Issue 中出现 Python 3.13 路径线索，但未将其列为根因。
确认 Elasticsearch 是否可达，例如 es01:9200 是否能正常响应。
确认启动日志中是否出现“RAGFlow server is ready”之后立即跟 task_executor.py 的 usage / unrecognized arguments 报错。
确认 entrypoint.sh 中启动 task_executor.py 的命令形态，重点看是否存在裸位置参数。
确认 task_executor.py 的 argparse 定义仍为 -i/–index 与 -t/–type，而不是位置参数。

解决步骤

先查看容器启动日志，确认是否存在 task_executor.py: error: unrecognized arguments，并记录被误传的 worker/index 值，例如 44b2011eb929_0。
进入容器或从镜像中查看 docker/entrypoint.sh，定位启动 task_executor.py 的那一行，确认它是把 worker ID 作为位置参数传入，还是正确传给了 -i/–index。
查看 task_executor.py 的帮助或 argparse 段，确认参数形式只有 -i/–index 和 -t/–type，不支持裸位置参数。
根据维护者回复“this issue has been fixed”，优先更新 RAGFlow 到已包含该修复的版本或镜像，而不是在旧镜像中手动打补丁。
如果无法立即更新，可优先尝试在 entrypoint.sh 中将误传的 worker ID 改为 -i 参数传入，但这是基于 Issue 的推断性修复，需先备份并自行验证；Issue 未提供官方手动改法。
更新或调整后重启 RAGFlow 容器，再次触发文档 ingest，检查 task_executor.py 是否还报 unrecognized arguments。

验证方法

重启后观察容器日志：不应再出现 task_executor.py: error: unrecognized arguments；API 和 Elasticsearch 仍应保持正常返回，例如 POST /api/v1/documents/ingest 返回 200；同时后台文档解析任务应能正常启动并推进，而不是只在服务端返回 200 后停滞。若日志中仍有同样的 usage 报错，说明修复未生效或版本未更新到包含修复的提交。