mirror of
https://github.com/langgenius/dify-plugin-daemon.git
synced 2026-07-21 17:25:23 -04:00
Dify plugin fails to connect to milvus DB #136
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @cislove98 on GitHub (Jun 9, 2025).
Self Checks
To make sure we get to you in time, please check the following :)
Versions
Describe the bug
Dify plugin fails to connect to milvus DB
Connections to the milvus DB will connect normally in other local environments. The connection to milvus only fails when you run Retrieval Testing.
I ran the plugin as a debugging plugin with python -m main.
After that, when I run Retrieval Testing on knowledge, I get an error like below.
api-1 | 2025-06-09 09:04:47.501 INFO [Dummy-1] [external.py:202] - 📖📖📖external knowledge test start📖📖📖
api-1 | 2025-06-09 09:04:47.509 INFO [Dummy-1] [external.py:207] - dataset: <models.dataset.Dataset object at 0xffffa64d2210>
api-1 | 2025-06-09 09:04:47.510 INFO [Dummy-1] [external.py:222] - 📖📖📖external retrieve start📖📖📖
api-1 | 2025-06-09 09:04:47.515 INFO [Dummy-1] [external_knowledge_service.py:303] - 📖📖📖process external api📖📖📖
api-1 | 2025-06-09 09:04:47.516 INFO [Dummy-1] [external_knowledge_service.py:304] - url: http://host.docker.internal:8444/e/qds1zifok7avjf8s/retrieval
api-1 | 2025-06-09 09:04:47.516 INFO [Dummy-1] [external_knowledge_service.py:305] - params: {'retrieval_setting': {'top_k': 2, 'score_threshold': 0.0}, 'query': 'Purchase Inventory', 'knowledge_id': 'Vector_index_73684e8b_ddc3_4344_9af8_70882abf7792_Node', 'metadata_condition': None}
api-1 | 2025-06-09 09:04:47.516 INFO [Dummy-1] [external_knowledge_service.py:306] - headers: {'Content-Type': 'application/json', 'Authorization': 'Bearer 797328f1-8f09-4ee2-94d8-84b5e838932b'}
sandbox-1 | [GIN] 2025/06/09 - 09:04:48 | 200 | 45.084µs | ::1 | GET "/health"
api-1 | 2025-06-09 09:04:52.562 WARNING [Dummy-1] [ssrf_proxy.py:79] - Request to URL http://host.docker.internal:8444/e/qds1zifok7avjf8s/retrieval failed on attempt 1: timed out
nginx-1 | 172.66.0.243 - - [09/Jun/2025:09:04:52 +0000] "POST /e/qds1zifok7avjf8s/retrieval HTTP/1.1" 499 0 "-" "python-httpx/0.27.2" "172.19.0.8"
ssrf_proxy-1 | 1749459892.562 5003 172.19.0.8 TCP_MISS_ABORTED/000 0 POST http://host.docker.internal:8444/e/qds1zifok7avjf8s/retrieval - HIER_DIRECT/192.168.65.254 -
api-1 | 2025-06-09 09:04:58.122 WARNING [Dummy-1] [ssrf_proxy.py:79] - Request to URL http://host.docker.internal:8444/e/qds1zifok7avjf8s/retrieval failed on attempt 2: timed out
nginx-1 | 172.66.0.243 - - [09/Jun/2025:09:04:58 +0000] "POST /e/qds1zifok7avjf8s/retrieval HTTP/1.1" 499 0 "-" "python-httpx/0.27.2" "172.19.0.8"
ssrf_proxy-1 | 1749459898.122 5002 172.19.0.8 TCP_MISS_ABORTED/000 0 POST http://host.docker.internal:8444/e/qds1zifok7avjf8s/retrieval - HIER_DIRECT/192.168.65.254 -
api-1 | 2025-06-09 09:05:04.175 WARNING [Dummy-1] [ssrf_proxy.py:79] - Request to URL http://host.docker.internal:8444/e/qds1zifok7avjf8s/retrieval failed on attempt 3: timed out
nginx-1 | 172.66.0.243 - - [09/Jun/2025:09:05:04 +0000] "POST /e/qds1zifok7avjf8s/retrieval HTTP/1.1" 499 0 "-" "python-httpx/0.27.2" "172.19.0.8"
ssrf_proxy-1 | 1749459904.175 5001 172.19.0.8 TCP_MISS_ABORTED/000 0 POST http://host.docker.internal:8444/e/qds1zifok7avjf8s/retrieval - HIER_DIRECT/192.168.65.254 -
api-1 | 2025-06-09 09:05:11.241 WARNING [Dummy-1] [ssrf_proxy.py:79] - Request to URL http://host.docker.internal:8444/e/qds1zifok7avjf8s/retrieval failed on attempt 4: timed out
nginx-1 | 172.66.0.243 - - [09/Jun/2025:09:05:11 +0000] "POST /e/qds1zifok7avjf8s/retrieval HTTP/1.1" 499 0 "-" "python-httpx/0.27.2" "172.19.0.8"
api-1 | 2025-06-09 09:05:11.245 ERROR [Dummy-1] [app.py:875] - Exception on /console/api/datasets/f1fd02e0-705c-4d55-83a5-25356fe16405/external-hit-testing [POST]
api-1 | Traceback (most recent call last):
api-1 | File "/app/api/controllers/console/datasets/external.py", line 223, in post
api-1 | response = HitTestingService.external_retrieve(
api-1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
api-1 | File "/app/api/services/hit_testing_service.py", line 82, in external_retrieve
api-1 | all_documents = RetrievalService.external_retrieve(
api-1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
api-1 | File "/app/api/core/rag/datasource/retrieval_service.py", line 136, in external_retrieve
api-1 | all_documents = ExternalDatasetService.fetch_external_knowledge_retrieval(
nginx-1 | 172.66.0.243 - - [09/Jun/2025:09:05:11 +0000] "POST /console/api/datasets/f1fd02e0-705c-4d55-83a5-25356fe16405/external-hit-testing HTTP/1.1" 500 161 "http://localhost:8444/datasets/f1fd02e0-705c-4d55-83a5-25356fe16405/hitTesting" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Safari/537.36" "-"
api-1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
api-1 | File "/app/api/services/external_knowledge_service.py", line 308, in fetch_external_knowledge_retrieval
api-1 | response = ExternalDatasetService.process_external_api(
api-1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
api-1 | File "/app/api/services/external_knowledge_service.py", line 191, in process_external_api
api-1 | response: httpx.Response = getattr(ssrf_proxy, settings.request_method)(
api-1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
api-1 | File "/app/api/core/helper/ssrf_proxy.py", line 94, in post
api-1 | return make_request("POST", url, max_retries=max_retries, **kwargs)
api-1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
api-1 | File "/app/api/core/helper/ssrf_proxy.py", line 86, in make_request
api-1 | raise MaxRetriesExceededError(f"Reached maximum retries ({max_retries}) for URL {url}")
api-1 | core.helper.ssrf_proxy.MaxRetriesExceededError: Reached maximum retries (3) for URL http://host.docker.internal:8444/e/qds1zifok7avjf8s/retrieval
api-1 |
api-1 | During handling of the above exception, another exception occurred:
api-1 |
api-1 | Traceback (most recent call last):
api-1 | File "/app/api/.venv/lib/python3.12/site-packages/flask/app.py", line 917, in full_dispatch_request
api-1 | rv = self.dispatch_request()
api-1 | ^^^^^^^^^^^^^^^^^^^^^^^
api-1 | File "/app/api/.venv/lib/python3.12/site-packages/flask/app.py", line 902, in dispatch_request
api-1 | return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args) # type: ignore[no-any-return]
api-1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
api-1 | File "/app/api/.venv/lib/python3.12/site-packages/flask_restful/__init__.py", line 489, in wrapper
api-1 | resp = resource(*args, **kwargs)
api-1 | ^^^^^^^^^^^^^^^^^^^^^^^^^
api-1 | File "/app/api/.venv/lib/python3.12/site-packages/flask/views.py", line 110, in view
api-1 | return current_app.ensure_sync(self.dispatch_request)(**kwargs) # type: ignore[no-any-return]
api-1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
api-1 | File "/app/api/.venv/lib/python3.12/site-packages/flask_restful/__init__.py", line 604, in dispatch_request
api-1 | resp = meth(*args, **kwargs)
api-1 | ^^^^^^^^^^^^^^^^^^^^^
api-1 | File "/app/api/controllers/console/wraps.py", line 199, in decorated
api-1 | return view(*args, **kwargs)
api-1 | ^^^^^^^^^^^^^^^^^^^^^
api-1 | File "/app/api/libs/login.py", line 61, in decorated_view
api-1 | return current_app.ensure_sync(func)(*args, **kwargs)
api-1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
api-1 | File "/app/api/controllers/console/wraps.py", line 31, in decorated
api-1 | return view(*args, **kwargs)
api-1 | ^^^^^^^^^^^^^^^^^^^^^
api-1 | File "/app/api/controllers/console/datasets/external.py", line 233, in post
api-1 | raise InternalServerError(str(e))
api-1 | werkzeug.exceptions.InternalServerError: 500 Internal Server Error: Reached maximum retries (3) for URL http://host.docker.internal:8444/e/qds1zifok7avjf8s/retrieval
ssrf_proxy-1 | 1749459911.241 5005 172.19.0.8 TCP_MISS_ABORTED/000 0 POST http://host.docker.internal:8444/e/qds1zifok7avjf8s/retrieval - HIER_DIRECT/192.168.65.254 -
Expected behavior
When I run Retrieval Testing, I want it to connect with milvus inside the plugin's _invoke function to search for vectors.
Screenshots
Additional context
Add any other context about the problem here.
@sumansuhag commented on GitHub (Jun 9, 2025):
Hey cislove98,
Thanks for bringing up the issue with the Dify plugin not connecting to Milvus during Retrieval Testing. You've given us some solid logs that show there’s a timeout when api-1 tries to reach http://host.docker.internal:8444/e/qds1zifok7avjf8s/retrieval.
This MaxRetriesExceededError means the Dify plugin container can’t connect to the service it’s looking for at host.docker.internal:8444. Since Milvus is working fine in other local setups, this points to a problem with network connectivity or service exposure in your Docker environment, not with Milvus itself.
The host.docker.internal is a special name that leads to the internal IP address of your Docker host machine. The timeouts here suggest that the service expected on port 8444 is either:
Here are some steps to help you troubleshoot the issue:
Check the Service at 8444:
On your host machine (not in any Docker container), see if you can curl http://localhost:8444/health or whatever endpoint that service has. Make sure the service the Dify plugin is trying to reach is actually up and running.
Identify the Expected Service:
What service is supposed to be at http://host.docker.internal:8444/e/qds1zifok7avjf8s/retrieval? Is it the Dify plugin’s API for knowledge retrieval that talks to Milvus, or is it directly Milvus?
Look at Docker Network Settings:
Check your docker-compose.yml or Docker run commands. Make sure that all services (Dify api-1, your Milvus instance, and the plugin if it's separate) are in the same Docker network. If Milvus is running in a Docker container with Dify, the Dify plugin should usually connect to Milvus using its Docker service name (like milvus:19530) instead of host.docker.internal.
Firewall Check:
Try temporarily disabling any firewalls on your macOS or other OS to see if they’re blocking port 8444.
Test Connectivity from the api-1 Container:
Get a shell in your api-1 container: docker exec -it <api-1_container_id_or_name> sh (or bash).
Inside that shell, check basic connectivity with: ping host.docker.internal.
Then, try curling http://host.docker.internal:8444/e/qds1zifok7avjf8s/retrieval to see what response or error you get.
The ssrf_proxy timing out lines up with the backend service it’s trying to connect to not being reachable.
Figuring out what should be listening on host.docker.internal:8444 and how it’s set up will be key to solving this.
@cislove98 commented on GitHub (Jun 10, 2025):
Hi sumansuhag
Thank you for taking the time to think about my issue.
To give you a brief context of the issue, I am currently working on a new plugin to test milvus connections.
I am developing it with dify CLI as per the description written in dify-plugin-daemon.
The category of the plugin is extgension.
The endpoint is configured as shown in the image below.
In the python code of the endpoint, I am trying to connect to milvus.
To test the plugin in development, I executed the plugin with python -m main and found that it is using
All the settings for the test went fine.
In the python code of the plugin
I am using pymilvus and the URI is trying to access http://:19531.
However, when I try to access it from inside the _invoke function, I'm having trouble connecting.
When I tested accessing that milvus address with curl from the plugin_daemon, api-1 container of dify, I found that it accesses fine.
I ran it with python -m main, so I think it's running in a local environment, so I don't think it's a network issue with docker.
When I access milvus inside the _invoke function, I can't connect even if I enter the direct milvus IP address, so I don't think it's related to special names like localhost, host.docker.internal.
When I send a request to that plugin with postman, it appears as the image below.
Is there a solution?
@sumansuhag commented on GitHub (Jun 11, 2025):
Hi,
This is a complex technical issue related to Dify plugin development and
connecting to a Milvus database. Unfortunately, I cannot directly debug
code or provide specific technical support for software development
problems.
However, here are some suggestions that might help you find a solution:
official documentation for any specific instructions or troubleshooting
steps related to database connections.
issues reported by other users. There might be existing solutions or
workarounds.
correct procedures for connecting to Milvus from within a Python
application. Pay close attention to network configurations and
authentication settings.
on relevant forums, Discord servers, or Stack Overflow. Provide detailed
information about your setup, including code snippets and error messages.
I hope you can resolve this issue soon.
On Tue, Jun 10, 2025 at 2:16 AM 최인식 @.***> wrote:
@DawnOf1996 commented on GitHub (Oct 23, 2025):
I also had the same issue when using the milvus sdk.
I developed a tool-type plugin, which internally uses the Milvus SDK to connect to the milvus database, but there is a blocking problem when the execution is initialized to MilvusClient
This might be a problem with the sync or asyn execution between the MilvusSDK and Dify plugin runtime, buut not sure what exactly the problem is.
I reviewed the Milvus tools provided by the community, which internally use HTTP requests to connect to the Milvus database
I hope this helps you