dify - 💡(How to fix) Fix Knowledge Retrieval Latency Caused by Weaviate Client Version Check in Self-Hosted Environments

Self Checks

• I have read the Contributing Guide and Language Policy.
• This is only for bug report, if you would like to ask a question, please head to Discussions.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report, otherwise it will be closed.
• 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
• Please do not modify this template :) and fill in all the required fields.

Dify version

1.9.2

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

Environment

• Dify Self-hosted
• Docker Compose Deployment
• Weaviate Vector Database
• Ubuntu Server
• Corporate Network Environment

Steps

1. Create a Knowledge Base

Create a knowledge base and import documents.

2. Create a Chatflow

Configure the workflow:

User Input → Knowledge Retrieval → LLM → Answer

3. Ask a Question

Example:

How to install YunGuan?

4. Observe Response Time

Expected response time:

0.5s ~ 2s

Actual response time:

9s ~ 12s

5. Verify Weaviate Health

Execute inside the Dify container network:

for i in {1..10}; do
  curl -o /dev/null -s \
  -w "ready 第${i}次: %{time_total}s\n" \
  http://weaviate:8080/v1/.well-known/ready
done

Result:

ready 第1次: 0.003757s
ready 第2次: 0.002037s
ready 第3次: 0.001799s
ready 第4次: 0.002364s
ready 第5次: 0.001453s

The Weaviate service responds within milliseconds.

6. Investigate Dify API Container

Search for version check logic:

grep -R "pypi.org/pypi/weaviate-client/json" \
/app/api/.venv/lib/python*/site-packages/weaviate

Result:

PYPI_PACKAGE_URL = "https://pypi.org/pypi/weaviate-client/json"

7. Network Observation

In environments where access to pypi.org is slow, blocked, or restricted, the retrieval workflow experiences significant delays.

The vector database remains healthy, but the overall knowledge retrieval latency increases substantially.

Result

Knowledge retrieval latency reaches:

9s ~ 12s

while the underlying Weaviate service responds in:

0.001s ~ 0.003s

This suggests the latency may be related to external dependency checks rather than vector search performance itself.

✔️ Expected Behavior

Expected Behavior

Knowledge retrieval performance should not be affected by external package registry availability.

When Weaviate is healthy and responding normally, retrieval latency should remain stable regardless of whether pypi.org is reachable.

Version checking behavior should:

1. Be disabled by default in production environments.
2. Execute asynchronously without blocking retrieval requests.
3. Be configurable through an environment variable.
4. Fail fast when external network access is unavailable.

Example:

DISABLE_WEAVIATE_VERSION_CHECK=true

Knowledge retrieval should continue to operate normally even in:

• Enterprise intranet deployments
• Air-gapped environments
• Restricted network environments
• Mainland China deployments with limited access to external services

Expected retrieval latency:

0.5s ~ 2s

when the vector database itself is healthy and responding within milliseconds.

❌ Actual Behavior

Actual Behavior

Knowledge retrieval requests experience significant latency.

Observed latency:

9s ~ 12s

while the Weaviate ready endpoint responds in:

0.001s ~ 0.003s

The issue appears only in environments where access to external package registry services is slow, restricted, or unavailable.

As a result, end users experience long wait times even though the vector database itself remains healthy.