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

[Feature Request] Expose a public API for observing the runtime #4

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

Originally created by @logan-markewich on GitHub (Jul 23, 2025).

Originally assigned to: @AstraBert on GitHub.

While the Context() currently manages a ton of stuff (asyncio queues, task workers for each workflow step, state, etc.), not all of this is exposed in a user-friendly way

It would be nice to have

  • public access to the start event CLS
  • public access to the stop event CLS
  • public API for checking the runtime state (which steps are running, are all queues exhausted, what events are waiting to be processed?)
    • This could be implemented as hooks as well (when events get added to queues, when steps error, when the state store changes)
Originally created by @logan-markewich on GitHub (Jul 23, 2025). Originally assigned to: @AstraBert on GitHub. While the `Context()` currently manages a ton of stuff (asyncio queues, task workers for each workflow step, state, etc.), not all of this is exposed in a user-friendly way It would be nice to have - public access to the start event CLS - public access to the stop event CLS - public API for checking the runtime state (which steps are running, are all queues exhausted, what events are waiting to be processed?) - This could be implemented as hooks as well (when events get added to queues, when steps error, when the state store changes)
yindo added the enhancement label 2026-02-16 02:16:03 -05:00
yindo closed this issue 2026-02-16 02:16:03 -05:00
yindo commented 2026-02-16 02:16:03 -05:00
Author
Owner
Copy Link
Copy Source

@logan-markewich commented on GitHub (Jul 29, 2025):

Maybe to expand on the third point a bit, I think it might be helpful to think of this in the context of frontend application built on top of workflows. If you have a hook like useWorkflow(..) in your frontend, you'd likely want to expose information about the workflow as it runs. While this can be captured by events that a workflow emits, these events are all manually written by the user

Instead, there is a lot of built-in utility we can expose/provide to let users get this info for free

  • currently active/running steps
  • which event those steps are working on
  • state changes/diffs

One suggestion is maybe handler.stream_events(include_internal=True) and we expose internal state changes through the event stream API, using pre-defined events?

@logan-markewich commented on GitHub (Jul 29, 2025): Maybe to expand on the third point a bit, I think it might be helpful to think of this in the context of frontend application built on top of workflows. If you have a hook like `useWorkflow(..)` in your frontend, you'd likely want to expose information about the workflow as it runs. While this can be captured by events that a workflow emits, these events are all manually written by the user Instead, there is a lot of built-in utility we can expose/provide to let users get this info for free - currently active/running steps - which event those steps are working on - state changes/diffs One suggestion is maybe `handler.stream_events(include_internal=True)` and we expose internal state changes through the event stream API, using pre-defined events?
yindo commented 2026-02-16 02:16:03 -05:00
Author
Owner
Copy Link
Copy Source

@AstraBert commented on GitHub (Aug 21, 2025):

I'll take a stab at this!

@AstraBert commented on GitHub (Aug 21, 2025): I'll take a stab at this!
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#4
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?