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

Introduce WorkflowResumptionContext for pause state management #20275

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

Originally created by @QuantumGhost on GitHub (Nov 12, 2025).

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.

PR #27298 introduces a model for saving the execution state when pausing workflow execution,
along with a layer for state persistence handling. However, the current implementation
of PauseStatePersistenceLayer has several limitations:

  1. Direct state serialization: The serialized GraphRuntimeState is saved directly to
    object storage without any wrapper structure. This approach makes it difficult to add additional
    metadata that might be necessary for resumption, such as InvokeFrom, user_id and streaming.

  2. Lack of version management: The saved state lacks comprehensive version management, making it
    challenging to evolve the codebase and handle data structure changes over time.
    While the serialized GraphRuntimeState itself includes version management, this is insufficient
    when combined with point 1, as it only allows for the evolution of GraphRuntimeState rather than
    the entire execution state.

To address these limitations, I propose introducing a new data model called ExecutionState that will
encapsulate all state information necessary for workflow resumption. This approach will provide:

  • A structured container for execution state
  • Comprehensive versioning support for the entire execution state, not just the runtime state

The ExecutionState model will serve as a wrapper around the GraphRuntimeState while
providing the flexibility needed for future enhancements and proper state management
throughout the workflow lifecycle.

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 @QuantumGhost on GitHub (Nov 12, 2025). ### 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. PR #27298 introduces a model for saving the execution state when pausing workflow execution, along with a layer for state persistence handling. However, the current implementation of `PauseStatePersistenceLayer` has several limitations: 1. **Direct state serialization**: The serialized `GraphRuntimeState` is saved directly to object storage without any wrapper structure. This approach makes it difficult to add additional metadata that might be necessary for resumption, such as `InvokeFrom`, `user_id` and `streaming`. 2. **Lack of version management**: The saved state lacks comprehensive version management, making it challenging to evolve the codebase and handle data structure changes over time. While the serialized `GraphRuntimeState` itself includes version management, this is insufficient when combined with point 1, as it only allows for the evolution of `GraphRuntimeState` rather than the entire execution state. To address these limitations, I propose introducing a new data model called `ExecutionState` that will encapsulate all state information necessary for workflow resumption. This approach will provide: - A structured container for execution state - Comprehensive versioning support for the entire execution state, not just the runtime state The `ExecutionState` model will serve as a wrapper around the `GraphRuntimeState` while providing the flexibility needed for future enhancements and proper state management throughout the workflow lifecycle. ### 2. Additional context or comments _No response_ ### 3. Can you help us with this feature? - [x] I am interested in contributing to this feature.
yindo added the 💪 enhancement🌊 feat:workflow labels 2026-02-21 20:06:38 -05:00
yindo closed this issue 2026-02-21 20:06:38 -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 🌊 feat:workflow 💪 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#20275
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?