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

[PR #32161] fix(api): infer workflow tool provider type when type is missing #33582

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

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

State: closed
Merged: No

Summary

This PR adds a backend fallback for Agent node tool provider type resolution when historical workflow data is missing type.

In upgraded deployments, some existing workflow-tool entries can still miss type/provider_type, which makes Agent node resolution default to built-in/plugin and can raise PluginNotFoundError at runtime.
close https://github.com/langgenius/dify/issues/32149

What changed

  • Added workflow provider ID detection for tool entries where type is missing.
  • Added _resolve_tool_provider_type(...) logic:
    • Keep explicit type when present.
    • Infer workflow when provider_name matches a WorkflowToolProvider in the same tenant.
    • Fallback to built_in otherwise.
  • Wired this resolution into Agent node array[tools] parameter normalization.
  • Added focused unit tests for:
    • Explicit type priority.
    • Workflow fallback path.
    • Built-in default path.
    • Provider lookup behavior.
    • Integration path through _generate_agent_parameters.

Why this is useful

This keeps existing upgraded workflows usable without requiring manual DB patching, while preserving behavior for correctly typed tools and non-workflow providers.

Validation

Local checks run successfully:

  • uv run --project api --group dev ruff check api/core/workflow/nodes/agent/agent_node.py api/tests/unit_tests/core/workflow/nodes/agent/test_agent_node_tool_provider_type.py
  • uv run --project api --group dev pytest api/tests/unit_tests/core/workflow/nodes/agent/test_agent_node_tool_provider_type.py -q
  • uv run --project api --group dev pytest -o addopts='' api/tests/unit_tests/core/workflow/nodes/agent/test_agent_node_tool_provider_type.py -q --cov=core.workflow.nodes.agent.agent_node --cov-branch --cov-report=xml --cov-report=term-missing

Changed-lines coverage for api/core/workflow/nodes/agent/agent_node.py: 100% (19/19 executable changed lines covered).

**Original Pull Request:** https://github.com/langgenius/dify/pull/32161 **State:** closed **Merged:** No --- ## Summary This PR adds a backend fallback for Agent node tool provider type resolution when historical workflow data is missing `type`. In upgraded deployments, some existing workflow-tool entries can still miss `type`/`provider_type`, which makes Agent node resolution default to built-in/plugin and can raise `PluginNotFoundError` at runtime. close https://github.com/langgenius/dify/issues/32149 ## What changed - Added workflow provider ID detection for tool entries where `type` is missing. - Added `_resolve_tool_provider_type(...)` logic: - Keep explicit `type` when present. - Infer `workflow` when `provider_name` matches a `WorkflowToolProvider` in the same tenant. - Fallback to `built_in` otherwise. - Wired this resolution into Agent node `array[tools]` parameter normalization. - Added focused unit tests for: - Explicit type priority. - Workflow fallback path. - Built-in default path. - Provider lookup behavior. - Integration path through `_generate_agent_parameters`. ## Why this is useful This keeps existing upgraded workflows usable without requiring manual DB patching, while preserving behavior for correctly typed tools and non-workflow providers. ## Validation Local checks run successfully: - `uv run --project api --group dev ruff check api/core/workflow/nodes/agent/agent_node.py api/tests/unit_tests/core/workflow/nodes/agent/test_agent_node_tool_provider_type.py` - `uv run --project api --group dev pytest api/tests/unit_tests/core/workflow/nodes/agent/test_agent_node_tool_provider_type.py -q` - `uv run --project api --group dev pytest -o addopts='' api/tests/unit_tests/core/workflow/nodes/agent/test_agent_node_tool_provider_type.py -q --cov=core.workflow.nodes.agent.agent_node --cov-branch --cov-report=xml --cov-report=term-missing` Changed-lines coverage for `api/core/workflow/nodes/agent/agent_node.py`: **100%** (19/19 executable changed lines covered).
yindo added the pull-request label 2026-02-21 20:53:32 -05:00
yindo closed this issue 2026-02-21 20:53:32 -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#33582
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?