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

[PR #6] [CLOSED] [WIP] Add Typed Workflow State #41

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

📋 Pull Request Information

Original PR: https://github.com/run-llama/workflows-py/pull/6
Author: @logan-markewich
Created: 6/12/2025
Status: ❌ Closed

Base: main ← Head: logan/typed_state_poc

📝 Commits (2)

📊 Changes

1 file changed (+121 additions, -0 deletions)

View changed files

➕ src/workflows/context/state_manager.py (+121 -0)

📄 Description

Currently, the Context provides an async and untyped get/set API

Pros:

  • easy to use
  • always there
  • async, so maybe someday it can be easily backed by some DB

Cons:

  • untyped
  • serialization nightmare

This PR introduces a concept of a state manager. The idea is to capture the same pros as the current workflow state, but also fix the cons.

This API would be opt-in. My current thinking is to use type annotations to set the state class.

class MyState(BaseModel):
        name: str
        age: int
    
class MyWorkflow(Workflow):
    @step
    async def step_1(self, ctx: Annotated[Context, MyState], ev: StartEvent) -> StopEvent:
        state = await ctx.state.get()
        state.name = "John"
        state.age = 30
        await ctx.state.set(state)

        return StopEvent()

Pros:

  • opt-in / non-breaking
  • async
  • type safe
  • allows for partial access of fields (i.e. state.get_path("some.nested.field")) -- this loses type safety but is DB friendly
  • user controls serialization (because its a pydantic class)

Cons:

  • Not sure how to make this singleton per workflow.run()
  • What if the user annotates two steps in a workflow with different pydantic state models?

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/run-llama/workflows-py/pull/6 **Author:** [@logan-markewich](https://github.com/logan-markewich) **Created:** 6/12/2025 **Status:** ❌ Closed **Base:** `main` ← **Head:** `logan/typed_state_poc` --- ### 📝 Commits (2) - [`967637e`](https://github.com/run-llama/workflows-py/commit/967637ee440c92a5586d8263a03e4fe66670dc5f) wip - [`b3be007`](https://github.com/run-llama/workflows-py/commit/b3be0077effcebb8e66044dba2ca0aa6960c7b83) wip ### 📊 Changes **1 file changed** (+121 additions, -0 deletions) <details> <summary>View changed files</summary> ➕ `src/workflows/context/state_manager.py` (+121 -0) </details> ### 📄 Description Currently, the `Context` provides an async and untyped get/set API Pros: - easy to use - always there - async, so maybe someday it can be easily backed by some DB Cons: - untyped - serialization nightmare This PR introduces a concept of a state manager. The idea is to capture the same pros as the current workflow state, but also fix the cons. This API would be opt-in. My current thinking is to use type annotations to set the state class. ``` class MyState(BaseModel): name: str age: int class MyWorkflow(Workflow): @step async def step_1(self, ctx: Annotated[Context, MyState], ev: StartEvent) -> StopEvent: state = await ctx.state.get() state.name = "John" state.age = 30 await ctx.state.set(state) return StopEvent() ``` Pros: - opt-in / non-breaking - async - type safe - allows for partial access of fields (i.e. `state.get_path("some.nested.field")`) -- this loses type safety but is DB friendly - user controls serialization (because its a pydantic class) Cons: - Not sure how to make this singleton per workflow.run() - What if the user annotates two steps in a workflow with different pydantic state models? --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
yindo added the pull-request label 2026-02-16 02:16:21 -05:00
yindo closed this issue 2026-02-16 02:16:21 -05:00
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 pull-request
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#41
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?