Issue Station
Sign In
Tools hereToolbox

crewai - ✅(Solved) Fix [BUG] Checkpoint TUI restore/fork path is Crew-only for Flow checkpoints [2 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
crewAIInc/crewAI#5492•Fetched 2026-04-17 08:30:33
View on GitHub
Comments
0
Participants
1
Timeline
7
Reactions
0
Author
shaun0927shaun0927
Participants
shaun0927shaun0927
Assignees
greysonlalondegreysonlalonde
Timeline (top)
cross-referenced ×3referenced ×2assigned ×1closed ×1

The checkpoint TUI restore/fork flow appears to be Crew-only.

Even though Flow.from_checkpoint() and Flow.fork() exist, the async TUI runner currently restores/forks through Crew.from_checkpoint() / Crew.fork() directly.

That means a Flow checkpoint selected from the TUI does not have a path that dispatches through the Flow restore/fork APIs.

Root Cause

The checkpoint TUI restore/fork flow appears to be Crew-only.

Even though Flow.from_checkpoint() and Flow.fork() exist, the async TUI runner currently restores/forks through Crew.from_checkpoint() / Crew.fork() directly.

That means a Flow checkpoint selected from the TUI does not have a path that dispatches through the Flow restore/fork APIs.

Fix Action

Fix / Workaround

That means a Flow checkpoint selected from the TUI does not have a path that dispatches through the Flow restore/fork APIs.

CrewAI’s README treats both Crews and Flows as first-class orchestration surfaces, and the recent checkpoint work explicitly added forking and TUI support. So Flow checkpoint dispatch in the TUI seems aligned with the current direction of the project rather than an edge case.

I verified locally with a stubbed TUI selection and fake runtime modules that both resume and fork dispatch through Crew, while Flow is never called.

PR fix notes

PR #5496: Fix #5492: Dispatch Flow checkpoints through Flow APIs in TUI

Description (problem / solution / changelog)

Summary

Fixes #5492 — the checkpoint TUI (_run_checkpoint_tui_async) was hardcoded to dispatch all restore/fork operations through Crew.from_checkpoint() / Crew.fork(), even when the selected checkpoint contained a Flow entity.

Changes:

  • Added CheckpointTUI._is_flow_checkpoint() static method that inspects the parsed checkpoint entry's entities for a "flow" type
  • Extended _TuiResult tuple to include an is_flow boolean flag, passed through from on_button_pressed
  • Modified _run_checkpoint_tui_async to dispatch through Flow.from_checkpoint() / Flow.fork() when a Flow entity is detected, and Crew.from_checkpoint() / Crew.fork() otherwise
  • Task output overrides (Crew-specific) are correctly skipped for Flow checkpoints

Review & Testing Checklist for Human

  • Verify that selecting a Flow checkpoint in the TUI dispatches through Flow.from_checkpoint() / Flow.fork() (not Crew)
  • Verify that selecting a Crew checkpoint in the TUI still works exactly as before
  • Confirm that task output overrides are skipped (not applied) for Flow checkpoints, since Flows don't expose .tasks at top level

Notes

  • 12 new tests added covering: flow entity detection, Flow resume/fork dispatch, Crew resume/fork dispatch, Flow with inputs, Flow skipping task overrides, and TUI quit behavior
  • All 59 tests in test_checkpoint.py pass, lint clean

Link to Devin session: https://app.devin.ai/sessions/70139e09eaf54cf6a598befee98706ea

<!-- CURSOR_SUMMARY -->

[!NOTE] Medium Risk Changes runtime dispatch logic for checkpoint resume/fork in the CLI, which could affect users restoring checkpoints if entity detection is wrong. Covered by new unit tests, and the change is isolated to the TUI execution path.

Overview Fixes checkpoint TUI restore/fork behavior by detecting whether the selected checkpoint contains a Flow entity and dispatching to Flow.from_checkpoint() / Flow.fork() instead of always using Crew.

Extends the TUI selection result to include an is_flow flag, adds CheckpointTUI._is_flow_checkpoint(), and ensures Crew-only task output overrides are skipped for Flow checkpoints. Adds async tests covering Flow vs Crew dispatch, input handling, override skipping, and quit behavior.

<sup>Reviewed by Cursor Bugbot for commit 1a7d0af602ce46a48736b6fdaafe6630015ad14d. Bugbot is set up for automated code reviews on this repo. Configure here.</sup>

<!-- /CURSOR_SUMMARY -->

Changed files

  • lib/crewai/src/crewai/cli/checkpoint_tui.py (modified, +39/-8)
  • lib/crewai/tests/test_checkpoint.py (modified, +146/-1)

PR #5503: fix: dispatch Flow checkpoints through Flow APIs in TUI

Description (problem / solution / changelog)

Summary

  • The checkpoint TUI (_run_checkpoint_tui_async) was hard-wired to Crew.from_checkpoint() / Crew.fork(), ignoring Flow checkpoints entirely
  • Added _detect_entity_type() that inspects the checkpoint entry's entities list for a "flow" entity type (the Pydantic discriminator already present in checkpoint data)
  • When a Flow checkpoint is selected, the TUI now dispatches through Flow.from_checkpoint() / Flow.fork() and kickoff_async()
  • Extended the TUI result tuple to carry the Literal["crew", "flow"] entity type

Closes #5492

Test plan

  • Existing test_checkpoint.py suite passes (47/47)
  • Manual: create a Flow checkpoint, open TUI, resume — verify Flow.from_checkpoint() is called
  • Manual: fork a Flow checkpoint from TUI — verify Flow.fork() is called
  • Manual: Crew checkpoints still resume/fork as before
<!-- CURSOR_SUMMARY -->

[!NOTE] Medium Risk Touches checkpoint resumption paths for both the CLI TUI and Flow.kickoff_async(), which can affect correctness of resume/fork behavior and runtime state handling across flows and crews.

Overview The checkpoint TUI now detects whether a selected checkpoint represents a crew or a flow and returns that type as part of the selection tuple.

When a flow checkpoint is chosen, resume/fork is dispatched via Flow.from_checkpoint() / Flow.fork() and executed with kickoff_async(); task-output overrides are still supported by mapping the flat TUI task indices back onto the underlying restored Crew entities. The task-override mutation logic is refactored into a reusable _apply_task_overrides() helper.

Flow.kickoff_async() now treats checkpoints restored via checkpoint_completed_methods as a restore scenario to avoid clearing execution state on resume.

<sup>Reviewed by Cursor Bugbot for commit 60bf510ed7566e58ad415ef7f9b6cf9d4e39e2b4. Bugbot is set up for automated code reviews on this repo. Configure here.</sup>

<!-- /CURSOR_SUMMARY -->

Changed files

  • lib/crewai/src/crewai/cli/checkpoint_tui.py (modified, +117/-53)
  • lib/crewai/src/crewai/flow/flow.py (modified, +3/-1)

Code Example

from crewai.crew import Crew
...
if action == "fork":
    crew = Crew.fork(config)
else:
    crew = Crew.from_checkpoint(config)

---

{"crew_fork": 1, "crew_resume": 1, "flow_fork": 0, "flow_resume": 0}
RAW_BUFFERClick to expand / collapse

Summary

The checkpoint TUI restore/fork flow appears to be Crew-only.

Even though Flow.from_checkpoint() and Flow.fork() exist, the async TUI runner currently restores/forks through Crew.from_checkpoint() / Crew.fork() directly.

That means a Flow checkpoint selected from the TUI does not have a path that dispatches through the Flow restore/fork APIs.

Why this seems worth tracking

CrewAI’s README treats both Crews and Flows as first-class orchestration surfaces, and the recent checkpoint work explicitly added forking and TUI support. So Flow checkpoint dispatch in the TUI seems aligned with the current direction of the project rather than an edge case.

Relevant code path

In crewai/cli/checkpoint_tui.py, _run_checkpoint_tui_async() currently does this after the user makes a selection:

from crewai.crew import Crew
...
if action == "fork":
    crew = Crew.fork(config)
else:
    crew = Crew.from_checkpoint(config)

I verified locally with a stubbed TUI selection and fake runtime modules that both resume and fork dispatch through Crew, while Flow is never called.

Observed call counts from the local repro:

{"crew_fork": 1, "crew_resume": 1, "flow_fork": 0, "flow_resume": 0}

Expected behavior

If the selected checkpoint contains a Flow entity, the TUI should restore/fork through:

  • Flow.from_checkpoint()
  • Flow.fork()

Actual behavior

The TUI dispatch path is hard-wired to Crew, so Flow checkpoints do not appear to have a dedicated restore/fork path from the TUI.

Related

  • #5381
  • #5387

This report was drafted with AI assistance. I was not able to apply an llm-generated label from my account.

extent analysis

TL;DR

Modify the TUI runner in crewai/cli/checkpoint_tui.py to conditionally use Flow.from_checkpoint() and Flow.fork() based on the type of checkpoint selected.

Guidance

  • Identify the type of checkpoint (Crew or Flow) selected by the user in the TUI and store this information in a variable.
  • Use an if-else statement to conditionally call either Crew.from_checkpoint()/Crew.fork() or Flow.from_checkpoint()/Flow.fork() based on the checkpoint type.
  • Update the _run_checkpoint_tui_async() function to incorporate this conditional logic.
  • Verify the fix by checking the call counts of crew_fork, crew_resume, flow_fork, and flow_resume to ensure that Flow checkpoints are correctly dispatched through Flow APIs.

Example

if action == "fork":
    if checkpoint_type == "Flow":
        crew = Flow.fork(config)
    else:
        crew = Crew.fork(config)
else:
    if checkpoint_type == "Flow":
        crew = Flow.from_checkpoint(config)
    else:
        crew = Crew.from_checkpoint(config)

Notes

The exact implementation may vary depending on how the checkpoint type is determined and stored. This example assumes that checkpoint_type is a variable that holds the type of checkpoint selected by the user.

Recommendation

Apply workaround: Modify the TUI runner to conditionally use Flow.from_checkpoint() and Flow.fork() based on the type of checkpoint selected, as this will allow Flow checkpoints to be correctly restored/forked from the TUI.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

If the selected checkpoint contains a Flow entity, the TUI should restore/fork through:

  • Flow.from_checkpoint()
  • Flow.fork()
#api#serialization error#model compatibility#GPU setup#container setup

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING