issue: Uploads fail in Qdrant multitenancy mode (the default) when strict mode is enabled with max_query_limit below 999999999

快速结论：在 Qdrant 启用 strict mode 且 max_query_limit 小于 999999999 时，Open WebUI 的 Qdrant 集成会用一次性超大请求（limit=999999999）读取整个集合，被 Qdrant 以 HTTP 400 拒绝，导致第二次文件上传失败、混合检索返回 0 条文档。优先检查 Qdrant 的 max_query_limit 是否过低。

适用环境：Open WebUI v0.11.4（官方 PyPI wheel）以及 dev 分支；Pip 安装；CachyOS（Arch 系）Linux 7.1 x86_64；Qdrant 作为向量库（Issue 中引用 v1.19.0 的配置）；Ollama 未涉及；浏览器无关，故障在服务端。

最快修复方案：在 Qdrant 侧把 max_query_limit 提高到至少 999999999。该做法由维护者在讨论中确认为当前可用 workaround。

注意事项：把 max_query_limit 调高只是绕过限制，会让超大单次读取继续生效，可能带来内存或性能压力。核心中的混合检索空结果问题已由 PR #31460 修复，Qdrant 集成侧的读取问题由 PR #31461 修复。此外后续评论指出：在 Chroma、关闭多租户的 Qdrant（以及代码阅读判断的 OpenSearch）上，新建的空知识库查询可能返回 400，因为 get() 对不存在的集合抛错并被计为失败；这是后续发现，属于修复后引入的副作用。

问题场景

用户使用 Open WebUI 并接入 Qdrant 作为向量库，采用默认的多租户（multitenancy）模式。Qdrant 部署启用了 strict mode，并把 max_query_limit 设为 1000（低于 Open WebUI 使用的 999999999）。在此配置下上传文件时：第一次上传成功，第二次上传失败，接口 POST /api/v1/files/ 虽返回 200，但 process_file 阶段因 Qdrant 返回 400 而以 failed 状态结束。之后对第二个文件的显式 POST /api/v1/retrieval/process/file、重新处理第一个文件、把第一个文件加入知识库，都会返回 400。

同时，在 ENABLE_RAG_HYBRID_SEARCH=true 时，对第一个文件的集合调用 POST /api/v1/retrieval/query/collection 返回 HTTP 200 但 0 条文档；关闭混合检索则返回 1 条。即使单次请求里传 "hybrid": false，只要服务端全局开启了混合检索，仍会返回 0 条。

报错原文

issue: Uploads fail in Qdrant multitenancy mode (the default) when strict mode is enabled with max_query_limit below 999999999

Qdrant returned a 400 during file processing (process_file)

_fetch_collection failing with the 400, then Starting hybrid search

[ERROR: Error querying knowledge base]

原因分析

最可能的原因是 Qdrant 客户端的读取方式与 strict mode 限制冲突：两个 Qdrant 客户端都用单次 scroll 调用读取“全部”数据，limit=NO_LIMIT（即 999999999）。Qdrant 的 strict mode 是可选且默认关闭的，本部署启用后把 max_query_limit 限制为 1000，于是该请求被 Qdrant 以 HTTP 400 拒绝。

在多租户默认模式下，第一次上传会成功创建 open-webui_files，不涉及 scroll；第二次上传时，save_docs_to_vector_db 中用于哈希去重的 query() 未传 limit，触发 400。加入知识库同样调用不带 limit 的 query()，因此也失败。

混合检索方面，Qdrant 客户端没有原生混合检索，query_collection_with_hybrid_search 会对每个集合用 get() 预取，而 get() 同样以 999999999 进行 scroll。它先通过 _fetch_collection，该函数记录 400 后把结果存为 None，导致该集合被跳过；failed_collection_names 只记录单次查询错误，所以函数最终返回空结果而不抛异常，依赖异常的向量检索回退逻辑也就不会执行——这是空结果的核心 bug。非多租户模式不会阻塞上传，但其混合检索同样返回 0 条文档。

环境排查

Open WebUI 版本：确认是 v0.11.4（PyPI open-webui==0.11.4）或 dev 分支；Issue 中 dev 提交为 420b4a2797fa283cd15b5ee267380743115eca5f，其 /api/version 仍报告 0.11.4。
安装方式：Pip 安装（dev 情况为从 Git clone 运行后端，前端未构建）。
操作系统：CachyOS（Arch 系），Linux 7.1，x86_64。
向量库：Qdrant，确认是否启用 strict mode，以及 max_query_limit 的取值。
向量库模式：确认是否为默认多租户（multitenancy）模式。
检索配置：确认 ENABLE_RAG_HYBRID_SEARCH 是否为 true。
Ollama：Issue 中明确未涉及，无需排查。

解决步骤

登录 Qdrant 部署，检查其配置中是否启用了 strict mode，以及 max_query_limit 当前值。
把 Qdrant 侧的 max_query_limit 提高到至少 999999999，然后重启/重载 Qdrant，使 Open WebUI 的单次大请求可以通过。这是维护者在讨论中给出的当前 workaround。
如需从代码侧修复上传失败：应用 Qdrant 集成相关修复（PR #31461），使读取不再以单个超大请求进行；Issue 后续确认该修复在 82afc7f 上验证通过，2500 个点的 get() 能以每页 1000 分页完整返回。
如需修复混合检索空结果：应用核心修复（PR #31460）。Issue 后续确认在 6aebfa6 上验证通过：当所有集合读取都失败时，默认查询会返回 API 的错误；传 "hybrid": false 时会回退到向量检索。
若你已应用上述修复，仍需留意后续发现的问题：在 Chroma、关闭多租户的 Qdrant（以及代码阅读判断的 OpenSearch）上，对新建且没有文件的知识库调用 POST /api/v1/retrieval/query/collection，在 dev（176d31d）上会返回 400 [ERROR: Error querying knowledge base]，而在 420b4a2 上返回 200 空结果；传 "hybrid": false 两者都返回 200 空结果。知识库放入文件后，两者都能返回其文档。该问题表现与 #12476 所处理的“空集合不执行检索”场景相关。

验证方法

按 Issue 给出的复现路径逐项验证：

上传：连续上传两个文件，确认第二次上传的 process_file 不再以 failed 结束；再对第二个文件执行 POST /api/v1/retrieval/process/file、重新处理第一个文件、把第一个文件加入知识库，确认均不再返回 400。
混合检索：在 ENABLE_RAG_HYBRID_SEARCH=true 下，对第一个文件的集合调用 POST /api/v1/retrieval/query/collection，确认能返回该文档而不是 0 条；应用 #31460 后，当集合读取全部失败时应返回 API 错误，传 "hybrid": false 时应回退到向量检索。
分页读取：应用 #31461 后，确认一个 2500 个点的 get() 能以每页 1000 的方式完整返回。
空知识库副作用：分别在有文件的空知识库上调用检索接口，确认 400 是否出现，以区分是否为该后续问题。