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

feat: Support specifying workflow version via workflow_id parameter #15784

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

Originally created by @qiaofenlin on GitHub (Jul 30, 2025).

Originally assigned to: @qiaofenlin on GitHub.

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report, otherwise it will be closed.
  • 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.

Current Challenge

In enterprise environments, we need the ability to specify particular workflow versions when making API calls. Currently, the system only uses the default published version, which limits our ability to:

  • Version Control: Maintain multiple workflow versions for different environments (dev, staging, production)
  • Stability: Lock to specific stable versions in production environments
  • Rollback Capability: Quickly switch back to previous versions if issues arise
  • A/B Testing: Test different workflow configurations without affecting production

Proposed Solution

Add an optional workflow_id parameter to API endpoints that allows users to specify a particular workflow version. If not provided, the system will use the default published version (maintaining backward compatibility).

Affected APIs

  • POST /v1/workflows/run - Execute workflow
  • POST /v1/chat-messages - Send chat message

Implementation Details

  • Parameter type: string
  • Required: false
  • Location: json request body
  • Default behavior: Use default published version if not specified

2. Additional context or comments

2. Additional context or comments

Enterprise Benefits

This enhancement will significantly improve enterprise deployment capabilities by providing:

  • Enhanced Stability: Lock to specific workflow versions for consistent production behavior
  • Better Scalability: Support multiple workflow versions simultaneously
  • Improved Version Management: Better integration with CI/CD pipelines
  • Risk Mitigation: Ability to quickly rollback to stable versions

Technical Impact

  • Backward compatible change
  • No breaking changes to existing API calls
  • Minimal code changes required
  • Comprehensive documentation updates included

Related Work

This feature aligns with enterprise requirements for production-grade workflow management and version control capabilities.

3. Can you help us with this feature?

  • I am interested in contributing to this feature.
Originally created by @qiaofenlin on GitHub (Jul 30, 2025). Originally assigned to: @qiaofenlin on GitHub. ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [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, otherwise it will be closed. - [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. ### Current Challenge In enterprise environments, we need the ability to specify particular workflow versions when making API calls. Currently, the system only uses the default published version, which limits our ability to: - **Version Control**: Maintain multiple workflow versions for different environments (dev, staging, production) - **Stability**: Lock to specific stable versions in production environments - **Rollback Capability**: Quickly switch back to previous versions if issues arise - **A/B Testing**: Test different workflow configurations without affecting production ### Proposed Solution Add an optional `workflow_id` parameter to API endpoints that allows users to specify a particular workflow version. If not provided, the system will use the default published version (maintaining backward compatibility). ### Affected APIs - `POST /v1/workflows/run` - Execute workflow - `POST /v1/chat-messages` - Send chat message ### Implementation Details - Parameter type: `string` - Required: `false` - Location: `json` request body - Default behavior: Use default published version if not specified ### 2. Additional context or comments ## 2. Additional context or comments ### Enterprise Benefits This enhancement will significantly improve enterprise deployment capabilities by providing: - **Enhanced Stability**: Lock to specific workflow versions for consistent production behavior - **Better Scalability**: Support multiple workflow versions simultaneously - **Improved Version Management**: Better integration with CI/CD pipelines - **Risk Mitigation**: Ability to quickly rollback to stable versions ### Technical Impact - Backward compatible change - No breaking changes to existing API calls - Minimal code changes required - Comprehensive documentation updates included ### Related Work This feature aligns with enterprise requirements for production-grade workflow management and version control capabilities. ### 3. Can you help us with this feature? - [x] I am interested in contributing to this feature.
yindo added the 💪 enhancement label 2026-02-21 19:23:19 -05:00
yindo closed this issue 2026-02-21 19:23:19 -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#15784
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?