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

[BorisPolonsky]

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 #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

dify/api/core/plugin/manager/base.py

Line 54 in 28edbba

url = URL(str(plugin_daemon_inner_api_baseurl)) / path

which is declared as

dify/api/core/plugin/manager/base.py

Line 32 in 28edbba

plugin_daemon_inner_api_baseurl = dify_config.PLUGIN_DAEMON_URL

while the exemplar docker-compose suggest PLUGIN_API_URL which doesn't match with the key PLUGIN_DAEMON_URL

dify/docker/docker-compose.yaml

Line 425 in 28edbba

PLUGIN_API_URL: ${PLUGIN_DAEMON_URL:-http://plugin_daemon:5002}

✔️ 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)"))