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

Include timeout exception in StopEvent.result for streaming workflows #27

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

Originally created by @ttozser on GitHub (Nov 19, 2025).

I have a workflow that streams events to the end user.
If the workflow times out, I receive an empty StopEvent without an indication of what the problem was.
I would like to receive the exception in the result field of the StopEvent so I can communicate the problem to the user.

For example:

exception = WorkflowTimeoutError(f"Operation timed out after {tick.timeout} seconds. {steps_info}")
return state, [
        CommandPublishEvent(event=StopEvent(result=exception)),
        CommandHalt(exception=exception),
    ]

I found these places with similar StopEvent. I think the exception should be provided in these places too.

https://github.com/AODocs-Dev/workflows-py/blob/300fd0541603d2496e6080bf9499205a0058df1c/packages/llama-index-workflows/src/workflows/runtime/control_loop.py#L438
https://github.com/AODocs-Dev/workflows-py/blob/300fd0541603d2496e6080bf9499205a0058df1c/packages/llama-index-workflows/src/workflows/runtime/control_loop.py#L653
https://github.com/AODocs-Dev/workflows-py/blob/300fd0541603d2496e6080bf9499205a0058df1c/packages/llama-index-workflows/src/workflows/runtime/control_loop.py#L681

Originally created by @ttozser on GitHub (Nov 19, 2025). I have a workflow that streams events to the end user. If the workflow times out, I receive an empty StopEvent without an indication of what the problem was. I would like to receive the exception in the result field of the StopEvent so I can communicate the problem to the user. ------------- For example: ``` exception = WorkflowTimeoutError(f"Operation timed out after {tick.timeout} seconds. {steps_info}") return state, [ CommandPublishEvent(event=StopEvent(result=exception)), CommandHalt(exception=exception), ] ``` I found these places with similar StopEvent. I think the exception should be provided in these places too. https://github.com/AODocs-Dev/workflows-py/blob/300fd0541603d2496e6080bf9499205a0058df1c/packages/llama-index-workflows/src/workflows/runtime/control_loop.py#L438 https://github.com/AODocs-Dev/workflows-py/blob/300fd0541603d2496e6080bf9499205a0058df1c/packages/llama-index-workflows/src/workflows/runtime/control_loop.py#L653 https://github.com/AODocs-Dev/workflows-py/blob/300fd0541603d2496e6080bf9499205a0058df1c/packages/llama-index-workflows/src/workflows/runtime/control_loop.py#L681
yindo closed this issue 2026-02-16 02:16:11 -05:00
yindo commented 2026-02-16 02:16:11 -05:00
Author
Owner
Copy Link
Copy Source

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

@ttozser I feel the pain here and have been planning on us implementing something to this effect. Agree that adding some information to these generic stop events would be a good direction to make it more informative. I have some reservations about putting it in the result field? There's some odd legacy semantics around StopEvents vs custom stop events and whether they "unwrap" the result in the workflow return value for compatibility reasons.

One possible idea to avoid building on that would be to rather have specific subclasses of StopEvent that instead have types and specific fields related to the failure mode of the workflow. For example a WorkflowTimedOutEvent event with the duration of the time out, or WorkflowHaltedEvent, and WorkflowFailedEvent with a serializable representation of the exception. Would love your feedback!

@adrianlyjak commented on GitHub (Nov 20, 2025): @ttozser I feel the pain here and have been planning on us implementing something to this effect. Agree that adding some information to these generic stop events would be a good direction to make it more informative. I have some reservations about putting it in the result field? There's some odd legacy semantics around StopEvents vs custom stop events and whether they "unwrap" the result in the workflow return value for compatibility reasons. One possible idea to avoid building on that would be to rather have specific subclasses of StopEvent that instead have types and specific fields related to the failure mode of the workflow. For example a `WorkflowTimedOutEvent` event with the duration of the time out, or `WorkflowHaltedEvent`, and `WorkflowFailedEvent` with a serializable representation of the exception. Would love your feedback!
yindo commented 2026-02-16 02:16:11 -05:00
Author
Owner
Copy Link
Copy Source

@ttozser commented on GitHub (Nov 21, 2025):

Having dedicated StopEvent subclasses is a good idea.
It solves my issue, and it has a lower chance of creating compatibility issues.

@ttozser commented on GitHub (Nov 21, 2025): Having dedicated StopEvent subclasses is a good idea. It solves my issue, and it has a lower chance of creating compatibility issues.
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
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#27
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?