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

[ENHANCEMENT] remove rudundant ENV variables and standardize names. #11139

New Issue
Closed
opened 2026-02-21 18:55:24 -05:00 by yindo · 0 comments
yindo commented 2026-02-21 18:55:24 -05:00
Owner
Copy Link
Copy Source

Originally created by @DavideDelbianco on GitHub (Mar 14, 2025).

Self Checks

  • 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.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

The docker compose passes the entire list of ENV variables to the api, worker and plugin_daemon services.
Then it is often common to see some of the variables copied into new ones, while already being injected.

This generates confusion in regards to which variables are really needed by each service
Please use the same names both in the code and in the docker-compose and stop adding every new ENV variable to the bookmarked section <<*shared-api-worker-env if they are nor really shared across projects.

example:
Image

PLUGIN_REMOTE_INSTALLING_HOST is copied from PLUGIN_DEBUGGING_HOST (those are already injected because of <<*shared-api-worker-env)
It should be either a remote debugging host or a remote install host... just choose the most appropriate name and make it consistent.

Another example is PLUGIN_MAX_EXECUTION_TIMEOUT or FORCE_VERIFYING_SIGNATURE:
Those variables are already injected with <<*shared-api-worker-env and the name does not even change...

  1. Are those ENVs really used in api and worker services ?
  2. Is it correct that they are part of the shared ENVs ? If the answer is Yes... then why copying them again with same name?

2. Additional context or comments

No response

3. Can you help us with this feature?

  • I am interested in contributing to this feature.
Originally created by @DavideDelbianco on GitHub (Mar 14, 2025). ### Self Checks - [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. ### 1. Is this request related to a challenge you're experiencing? Tell me about your story. The docker compose passes the entire list of ENV variables to the api, worker and plugin_daemon services. Then it is often common to see some of the variables copied into new ones, while already being injected. This generates confusion in regards to which variables are really needed by each service Please use the same names both in the code and in the docker-compose and stop adding every new ENV variable to the bookmarked section `<<*shared-api-worker-env` if they are nor really shared across projects. example: ![Image](https://github.com/user-attachments/assets/9d953a07-03d5-456d-8955-2544c08d087a) **PLUGIN_REMOTE_INSTALLING_HOST** is copied from **PLUGIN_DEBUGGING_HOST** (those are already injected because of `<<*shared-api-worker-env`) It should be either a remote _debugging_ host or a remote _install_ host... just choose the most appropriate name and make it consistent. Another example is **PLUGIN_MAX_EXECUTION_TIMEOUT** or **FORCE_VERIFYING_SIGNATURE**: Those variables are already injected with `<<*shared-api-worker-env` and the name does not even change... 1) Are those ENVs really used in api and worker services ? 2) Is it correct that they are part of the shared ENVs ? If the answer is Yes... then why copying them again with same name? ### 2. Additional context or comments _No response_ ### 3. Can you help us with this feature? - [ ] I am interested in contributing to this feature.
yindo added the 💪 enhancement label 2026-02-21 18:55:24 -05:00
yindo closed this issue 2026-02-21 18:55:24 -05:00
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 💪 enhancement
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#11139
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?