run-llama/workflows-py
1
0
Fork 0
mirror of https://github.com/run-llama/workflows-py.git synced 2026-07-21 04:05:25 -04:00
Code Issues 18 Packages Projects Releases 10 Wiki Activity

Support for Persistent Workflow Suspension and Resumption (for HITL event pauses) #24

New Issue
Closed
opened 2026-02-16 02:16:09 -05:00 by yindo · 4 comments
yindo commented 2026-02-16 02:16:09 -05:00
Owner
Copy Link
Copy Source

Originally created by @hidhana on GitHub (Nov 3, 2025).

In real-world use cases, human-in-the-loop responses can often take hours or even days to arrive. Currently, the workflow server is required to keep workflow state in memory while waiting for such responses, which is inefficient and limits scalability.

We propose introducing the ability to pause (persist) a workflow’s state to the workflow store when awaiting human input, rather than holding it in memory. Once the human response event is received, the workflow should be able to resume seamlessly from the persisted state.

This enhancement would improve reliability, scalability, and fault tolerance for long-running workflows involving asynchronous human participation.

Originally created by @hidhana on GitHub (Nov 3, 2025). In real-world use cases, human-in-the-loop responses can often take hours or even days to arrive. Currently, the workflow server is required to keep workflow state in memory while waiting for such responses, which is inefficient and limits scalability. We propose introducing the ability to pause (persist) a workflow’s state to the workflow store when awaiting human input, rather than holding it in memory. Once the human response event is received, the workflow should be able to resume seamlessly from the persisted state. This enhancement would improve reliability, scalability, and fault tolerance for long-running workflows involving asynchronous human participation.
yindo added the enhancement label 2026-02-16 02:16:09 -05:00
yindo closed this issue 2026-02-16 02:16:09 -05:00
yindo commented 2026-02-16 02:16:09 -05:00
Author
Owner
Copy Link
Copy Source

@logan-markewich commented on GitHub (Nov 3, 2025):

@hidhana this pattern is already supported

handler = w.run(...)
async for ev in handler.stream_events():
  if isinstance(ev, SomeEventThatRequiresHumanInput):
    ctx_data = handler.ctx.to_dict()
    await handler.cancel_run((

<store the dict anywhere you'd like>

new_ctx = Context.from_dict(MyWorkflow, ctx_data)
new_handler = w.run(.., ctx=new_ctx)
...

Basically you can save the context during a run, and restore it later to resume. Its just a JSON blob so you can put it wherever you need

@logan-markewich commented on GitHub (Nov 3, 2025): @hidhana this pattern is already supported ``` handler = w.run(...) async for ev in handler.stream_events(): if isinstance(ev, SomeEventThatRequiresHumanInput): ctx_data = handler.ctx.to_dict() await handler.cancel_run(( <store the dict anywhere you'd like> new_ctx = Context.from_dict(MyWorkflow, ctx_data) new_handler = w.run(.., ctx=new_ctx) ... ``` Basically you can save the context during a run, and restore it later to resume. Its just a JSON blob so you can put it wherever you need
yindo commented 2026-02-16 02:16:09 -05:00
Author
Owner
Copy Link
Copy Source

@adrianlyjak commented on GitHub (Nov 3, 2025):

@hidhana Thanks for the issue!

@logan-markewich I think this is referring to auto-pausing within the WorkflowServer, which is a great idea (sort of auto serializing the context when idle, and then only resuming when an event is sent). The tricky part is detecting when the workflow is idle. Might be trackable via the current internal events?

@adrianlyjak commented on GitHub (Nov 3, 2025): @hidhana Thanks for the issue! @logan-markewich I think this is referring to auto-pausing within the `WorkflowServer`, which is a great idea (sort of auto serializing the context when idle, and then only resuming when an event is sent). The tricky part is detecting when the workflow is idle. Might be trackable via the current internal events?
yindo commented 2026-02-16 02:16:10 -05:00
Author
Owner
Copy Link
Copy Source

@adrianlyjak commented on GitHub (Jan 6, 2026):

Initial start here https://github.com/run-llama/workflows-py/pull/261

@adrianlyjak commented on GitHub (Jan 6, 2026): Initial start here https://github.com/run-llama/workflows-py/pull/261
yindo commented 2026-02-16 02:16:10 -05:00
Author
Owner
Copy Link
Copy Source

@adrianlyjak commented on GitHub (Jan 12, 2026):

@hidhana this will go out in the next minor release (2.12.0)

@adrianlyjak commented on GitHub (Jan 12, 2026): @hidhana this will go out in the next minor release (2.12.0)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
enhancement
enhancement
good first issue
pull-request
Mirrored from GitHub Pull Request
 question
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: run-llama/workflows-py#24
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?