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

[PR #16817] fix: hardcoded provider id not correct #28586

New Issue
Closed
opened 2026-02-21 20:43:44 -05:00 by yindo · 0 comments
yindo commented 2026-02-21 20:43:44 -05:00
Owner
Copy Link
Copy Source

Original Pull Request: https://github.com/langgenius/dify/pull/16817

State: closed
Merged: No

Summary

The hardcoded tool used identity.name as its provider before Dify 1.0.0.

After Dify 1.0.0, it was forcibly changed to langgenius/<identity.name>/<identity.name>.

If a hardcoded tool is configured with credentials_for_provider, the current code will cause many issues. For example, when configuring credentials, the provider field inserted into tool_builtin_providers is langgenius/<identity.name>/<identity.name>. However, when querying the page again, it still looks for provider=<identity.name>, making it appear as if the tool has never been configured with credentials.

To ensure compatibility, I think the to_string method of the GenericProviderID class should check whether the tool is hardcoded. If it is, it should continue using <identity.name>. Otherwise, it should follow the Dify plugin marketplace format and use langgenius/<identity.name>/<identity.name>.

硬编码的tool，在dify1.0.0之前，使用的是identity.name作为它的provider。
在dify1.0.0之后，强行把它改成了langgenius/<identity.name>/<identity.name>
如果硬编码的tool配置了credentials_for_provider，现行代码中会导致很多问题，例如配置credentials的时候，插入tool_builtin_providers的provider字段的是langgenius/<identity.name>/<identity.name>，但是页面再次查询的时候还是查的provider=<identity.name>，导致认为该工具一直没配置密钥。

为了兼容这个问题，我觉得应该在GenericProviderID类的to_string方法，判断下如果是hardcoded的tool，仍然取<identity.name>，其它的按照dify插件市场的格式，走langgenius/<identity.name>/<identity.name>

Tip

Close issue syntax: Fixes #<issue number> or Resolves #<issue number>, see documentation for more details.

Screenshots

Before After
... ...

Checklist

Important

Please review the checklist below before submitting your pull request.

  • This change requires a documentation update, included: Dify Document
  • I understand that this PR may be closed in case there was no previous discussion or issues. (This doesn't apply to typos!)
  • I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change.
  • I've updated the documentation accordingly.
  • I ran dev/reformat(backend) and cd web && npx lint-staged(frontend) to appease the lint gods
**Original Pull Request:** https://github.com/langgenius/dify/pull/16817 **State:** closed **Merged:** No --- # Summary The hardcoded tool used identity.name as its provider before Dify 1.0.0. After Dify 1.0.0, it was forcibly changed to langgenius/<identity.name>/<identity.name>. If a hardcoded tool is configured with credentials_for_provider, the current code will cause many issues. For example, when configuring credentials, the provider field inserted into tool_builtin_providers is langgenius/<identity.name>/<identity.name>. However, when querying the page again, it still looks for provider=<identity.name>, making it appear as if the tool has never been configured with credentials. To ensure compatibility, I think the to_string method of the GenericProviderID class should check whether the tool is hardcoded. If it is, it should continue using <identity.name>. Otherwise, it should follow the Dify plugin marketplace format and use langgenius/<identity.name>/<identity.name>. 硬编码的tool，在dify1.0.0之前，使用的是identity.name作为它的provider。 在dify1.0.0之后，强行把它改成了langgenius/<identity.name>/<identity.name> 如果硬编码的tool配置了credentials_for_provider，现行代码中会导致很多问题，例如配置credentials的时候，插入tool_builtin_providers的provider字段的是langgenius/<identity.name>/<identity.name>，但是页面再次查询的时候还是查的provider=<identity.name>，导致认为该工具一直没配置密钥。 为了兼容这个问题，我觉得应该在GenericProviderID类的to_string方法，判断下如果是hardcoded的tool，仍然取<identity.name>，其它的按照dify插件市场的格式，走langgenius/<identity.name>/<identity.name> > [!Tip] > Close issue syntax: `Fixes #<issue number>` or `Resolves #<issue number>`, see [documentation](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) for more details. # Screenshots | Before | After | |--------|-------| | ... | ... | # Checklist > [!IMPORTANT] > Please review the checklist below before submitting your pull request. - [ ] This change requires a documentation update, included: [Dify Document](https://github.com/langgenius/dify-docs) - [x] I understand that this PR may be closed in case there was no previous discussion or issues. (This doesn't apply to typos!) - [x] I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change. - [x] I've updated the documentation accordingly. - [x] I ran `dev/reformat`(backend) and `cd web && npx lint-staged`(frontend) to appease the lint gods
yindo added the pull-request label 2026-02-21 20:43:44 -05:00
yindo closed this issue 2026-02-21 20:43:44 -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 pull-request
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#28586
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?