langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-21 20:15:31 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

Inconsistency between docker-compose.yaml and api on specifying entrypoint for pluginDaemon in v1.0.0-beta.1 #7931

New Issue
Closed
opened 2026-02-21 18:23:06 -05:00 by yindo · 3 comments
yindo commented 2026-02-21 18:23:06 -05:00
Owner
Copy Link
Copy Source

Originally created by @BorisPolonsky on GitHub (Jan 30, 2025).

Self Checks

  • 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 (我已阅读并同意 Language Policy).
  • [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:）
  • Please do not modify this template :) and fill in all the required fields.

Dify version

V1.0.0-beta.1

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

There are bug reports that suggest that api couldn't access devicePlugin in self hosting scenarios https://github.com/langgenius/dify/issues/12664. It appears that it's caused by an inconsistency between docker-compose (where PLUGIN_API_URL marks the entrypoint of pluginDaemon) and api (which actually reads from PLUGIN_DAEMON_URL instead of PLUGIN_API_URL as suggested in docker-compose.yaml)

To elaborate, api/worker defines entry for pluginDaemon as plugin_daemon_inner_api_baseurl
https://github.com/langgenius/dify/blob/28edbbac0b4f3da7403de1f00b6cf0a8e4c0e24b/api/core/plugin/manager/base.py#L54
which is declared as
https://github.com/langgenius/dify/blob/28edbbac0b4f3da7403de1f00b6cf0a8e4c0e24b/api/core/plugin/manager/base.py#L32
while the exemplar docker-compose suggest PLUGIN_API_URL which doesn't match with the key PLUGIN_DAEMON_URL
https://github.com/langgenius/dify/blob/28edbbac0b4f3da7403de1f00b6cf0a8e4c0e24b/docker/docker-compose.yaml#L425

✔️ Expected Behavior

Dify shall clarify which environment variable shall be used and fix this inconsistency.

To temporarily work around this inconsistency, one would have to switch environment variable from PLUGIN_API_URL to PLUGIN_DAEMON_URL in api:

Running migrations
2025-01-30 10:21:59,525.525 INFO [MainThread] [utils.py:162] - NumExpr defaulting to 12 threads.
Preparing database migration...
Starting database migration.
INFO  [alembic.runtime.migration] Context impl PostgresqlImpl.
INFO  [alembic.runtime.migration] Will assume transactional DDL.
Database migration successful!
[2025-01-30 10:22:06 +0000] [1] [INFO] Starting gunicorn 23.0.0
[2025-01-30 10:22:06 +0000] [1] [INFO] Listening at: http://0.0.0.0:5001 (1)
[2025-01-30 10:22:06 +0000] [1] [INFO] Using worker: gevent
[2025-01-30 10:22:06 +0000] [33] [INFO] Booting worker with pid: 33
2025-01-30 10:22:09,630.630 INFO [MainThread] [utils.py:162] - NumExpr defaulting to 12 threads.

❌ Actual Behavior

The api has fallen back to the default configuration (plugin in this case) as the domain of pluginDaemon hence failing to establish connection.

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/app/api/.venv/lib/python3.12/site-packages/requests/adapters.py", line 486, in send
    resp = conn.urlopen(
           ^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/urllib3/connectionpool.py", line 841, in urlopen
    retries = retries.increment(
              ^^^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/urllib3/util/retry.py", line 519, in increment
    raise MaxRetryError(_pool, url, reason) from reason  # type: ignore[arg-type]
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
urllib3.exceptions.MaxRetryError: HTTPConnectionPool(host='plugin', port=5002): Max retries exceeded with url: /plugin/7fd607f0-9b5a-496b-b69f-3abf8f5920b4/management/install/tasks?page=1&page_size=100 (Caused by NameResolutionError("<urllib3.connection.HTTPConnection object at 0x7fac9877c2f0>: Failed to resolve 'plugin' ([Errno -3] Temporary failure in name resolution)"))
Originally created by @BorisPolonsky on GitHub (Jan 30, 2025). ### Self Checks - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). - [x] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:） - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version V1.0.0-beta.1 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce There are bug reports that suggest that `api` couldn't access `devicePlugin` in self hosting scenarios https://github.com/langgenius/dify/issues/12664. It appears that it's caused by an inconsistency between `docker-compose` (where `PLUGIN_API_URL` marks the entrypoint of `pluginDaemon`) and `api` (which actually reads from `PLUGIN_DAEMON_URL` instead of `PLUGIN_API_URL` as suggested in `docker-compose.yaml`) To elaborate, `api`/`worker` defines entry for `pluginDaemon` as `plugin_daemon_inner_api_baseurl` https://github.com/langgenius/dify/blob/28edbbac0b4f3da7403de1f00b6cf0a8e4c0e24b/api/core/plugin/manager/base.py#L54 which is declared as https://github.com/langgenius/dify/blob/28edbbac0b4f3da7403de1f00b6cf0a8e4c0e24b/api/core/plugin/manager/base.py#L32 while the exemplar `docker-compose` suggest `PLUGIN_API_URL` which doesn't match with the key `PLUGIN_DAEMON_URL` https://github.com/langgenius/dify/blob/28edbbac0b4f3da7403de1f00b6cf0a8e4c0e24b/docker/docker-compose.yaml#L425 ### ✔️ Expected Behavior Dify shall clarify which environment variable shall be used and fix this inconsistency. To temporarily work around this inconsistency, one would have to switch environment variable from `PLUGIN_API_URL` to `PLUGIN_DAEMON_URL` in `api`: ``` Running migrations 2025-01-30 10:21:59,525.525 INFO [MainThread] [utils.py:162] - NumExpr defaulting to 12 threads. Preparing database migration... Starting database migration. INFO [alembic.runtime.migration] Context impl PostgresqlImpl. INFO [alembic.runtime.migration] Will assume transactional DDL. Database migration successful! [2025-01-30 10:22:06 +0000] [1] [INFO] Starting gunicorn 23.0.0 [2025-01-30 10:22:06 +0000] [1] [INFO] Listening at: http://0.0.0.0:5001 (1) [2025-01-30 10:22:06 +0000] [1] [INFO] Using worker: gevent [2025-01-30 10:22:06 +0000] [33] [INFO] Booting worker with pid: 33 2025-01-30 10:22:09,630.630 INFO [MainThread] [utils.py:162] - NumExpr defaulting to 12 threads. ``` ### ❌ Actual Behavior The `api` has fallen back to the default configuration (`plugin` in this case) as the domain of `pluginDaemon` hence failing to establish connection. ``` The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/app/api/.venv/lib/python3.12/site-packages/requests/adapters.py", line 486, in send resp = conn.urlopen( ^^^^^^^^^^^^^ File "/app/api/.venv/lib/python3.12/site-packages/urllib3/connectionpool.py", line 841, in urlopen retries = retries.increment( ^^^^^^^^^^^^^^^^^^ File "/app/api/.venv/lib/python3.12/site-packages/urllib3/util/retry.py", line 519, in increment raise MaxRetryError(_pool, url, reason) from reason # type: ignore[arg-type] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ urllib3.exceptions.MaxRetryError: HTTPConnectionPool(host='plugin', port=5002): Max retries exceeded with url: /plugin/7fd607f0-9b5a-496b-b69f-3abf8f5920b4/management/install/tasks?page=1&page_size=100 (Caused by NameResolutionError("<urllib3.connection.HTTPConnection object at 0x7fac9877c2f0>: Failed to resolve 'plugin' ([Errno -3] Temporary failure in name resolution)")) ```
yindo added the 🐞 bug label 2026-02-21 18:23:06 -05:00
yindo closed this issue 2026-02-21 18:23:06 -05:00
yindo commented 2026-02-21 18:23:06 -05:00
Author
Owner
Copy Link
Copy Source

@hjlarry commented on GitHub (Feb 2, 2025):

The issue has already been resolved in the plugin-beta branch: https://github.com/langgenius/dify/tree/plugins/beta

@hjlarry commented on GitHub (Feb 2, 2025): The issue has already been resolved in the plugin-beta branch: https://github.com/langgenius/dify/tree/plugins/beta
yindo commented 2026-02-21 18:23:06 -05:00
Author
Owner
Copy Link
Copy Source

@BorisPolonsky commented on GitHub (Feb 2, 2025):

The issue has already been resolved in the plugin-beta branch: https://github.com/langgenius/dify/tree/plugins/beta

https://github.com/langgenius/dify/blob/1de84fdda0ccb3b7f2754626f0ac4a402059a8a9/api/core/plugin/manager/base.py#L32

https://github.com/langgenius/dify/blob/1de84fdda0ccb3b7f2754626f0ac4a402059a8a9/docker/docker-compose.yaml#L395-L396

https://github.com/langgenius/dify/blob/1de84fdda0ccb3b7f2754626f0ac4a402059a8a9/docker/docker-compose.yaml#L423-L424

It looks like that dify_config.PLUGIN_DAEMON_URL remain in use by now, and both PLUGIN_DAEMON_URL and PLUGIN_API_URL were defined in docker-compose.yaml So it's still yet to be clarified which environment variable should be used for this purpose. I'd propose a new PR to remove redundant environment variables to avoid further confusion.

@BorisPolonsky commented on GitHub (Feb 2, 2025): > The issue has already been resolved in the plugin-beta branch: https://github.com/langgenius/dify/tree/plugins/beta https://github.com/langgenius/dify/blob/1de84fdda0ccb3b7f2754626f0ac4a402059a8a9/api/core/plugin/manager/base.py#L32 https://github.com/langgenius/dify/blob/1de84fdda0ccb3b7f2754626f0ac4a402059a8a9/docker/docker-compose.yaml#L395-L396 https://github.com/langgenius/dify/blob/1de84fdda0ccb3b7f2754626f0ac4a402059a8a9/docker/docker-compose.yaml#L423-L424 It looks like that `dify_config.PLUGIN_DAEMON_URL` remain in use by now, and both `PLUGIN_DAEMON_URL` and `PLUGIN_API_URL` were defined in `docker-compose.yaml` So it's still yet to be clarified which environment variable should be used for this purpose. I'd propose a new PR to remove redundant environment variables to avoid further confusion.
yindo commented 2026-02-21 18:23:06 -05:00
Author
Owner
Copy Link
Copy Source

@BorisPolonsky commented on GitHub (Feb 6, 2025):

Closed with https://github.com/langgenius/dify/pull/13239

@BorisPolonsky commented on GitHub (Feb 6, 2025): Closed with https://github.com/langgenius/dify/pull/13239
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label 🐞 bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#7931
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?