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

Inherited Workflow Classes with Subclassed States Raise "Multiple State Types" Error #33

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

Originally created by @schelv on GitHub (Jan 23, 2026).

Description

When subclassing a workflow and its associated State model using pydantic, running the child workflow raises the following error:

ValueError: Multiple state types are not supported. Make sure that each Context[...] has the same generic state type. Found: ChildState, BaseState

Reproduction

Here is a minimal example that demonstrates the issue:

from pydantic import BaseModel, Field
from workflows import Workflow, step, Context
from workflows.events import StartEvent, StopEvent

class BaseState(BaseModel):
    a: int = Field(default=1)

class ChildState(BaseState):
    b: str = Field(default="two")

class BaseWorkflow(Workflow):
    @step
    async def some_step(self, ctx: Context[BaseState], ev: StartEvent) -> StopEvent:
        return StopEvent()

class ChildWorkflow(BaseWorkflow):
    @step
    async def some_other_step(self, ctx: Context[ChildState], ev: StartEvent) -> StopEvent:
        return StopEvent()

workflow = ChildWorkflow()
workflow.run()

Expected Behavior

Since ChildState is a strict subclass of BaseState, I would expect this to be compatible. This pattern is common in Python and allows for reusable workflows with more specific state logic in child classes.

Actual Behavior

The framework raises a ValueError, seemingly due to the use of both BaseState and ChildState in different step contexts, even though ChildState is a subclass of BaseState.

Suggested Resolution

It would be ideal if subclassed states were treated as compatible, or at least a way to override the base class’s context type when subclassing workflows.

Originally created by @schelv on GitHub (Jan 23, 2026). ### Description When subclassing a workflow and its associated `State` model using `pydantic`, running the child workflow raises the following error: ``` ValueError: Multiple state types are not supported. Make sure that each Context[...] has the same generic state type. Found: ChildState, BaseState ``` ### Reproduction Here is a minimal example that demonstrates the issue: ```python from pydantic import BaseModel, Field from workflows import Workflow, step, Context from workflows.events import StartEvent, StopEvent class BaseState(BaseModel): a: int = Field(default=1) class ChildState(BaseState): b: str = Field(default="two") class BaseWorkflow(Workflow): @step async def some_step(self, ctx: Context[BaseState], ev: StartEvent) -> StopEvent: return StopEvent() class ChildWorkflow(BaseWorkflow): @step async def some_other_step(self, ctx: Context[ChildState], ev: StartEvent) -> StopEvent: return StopEvent() workflow = ChildWorkflow() workflow.run() ``` ### Expected Behavior Since `ChildState` is a strict subclass of `BaseState`, I would expect this to be compatible. This pattern is common in Python and allows for reusable workflows with more specific state logic in child classes. ### Actual Behavior The framework raises a `ValueError`, seemingly due to the use of both `BaseState` and `ChildState` in different step contexts, even though `ChildState` is a subclass of `BaseState`. ### Suggested Resolution It would be ideal if subclassed states were treated as compatible, or at least a way to override the base class’s context type when subclassing workflows.
yindo closed this issue 2026-02-16 02:16:12 -05:00
yindo commented 2026-02-16 02:16:13 -05:00
Author
Owner
Copy Link
Copy Source

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

This seems reasonable. Some changes need to be made to the state updates to properly support this, otherwise I think the more specific sub-type can get obliterated by an update with the parent type (Update does a replace rather than a shallow patch)

@adrianlyjak commented on GitHub (Jan 23, 2026): This seems reasonable. Some changes need to be made to the state updates to properly support this, otherwise I think the more specific sub-type can get obliterated by an update with the parent type (Update does a replace rather than a shallow patch)
yindo commented 2026-02-16 02:16:13 -05:00
Author
Owner
Copy Link
Copy Source

@adrianlyjak commented on GitHub (Feb 5, 2026):

@schelv released just now in v2.14.0

@adrianlyjak commented on GitHub (Feb 5, 2026): @schelv released just now in v2.14.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
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#33
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?