microsoft / microsoft/agent-framework

Python: Question: How to tell if a WorkflowCheckpoint is at a topological end (no outgoing edges)?

Open
#8,148 1 comment 0 reactions 1 assignee View on GitHub

@moonbox3 is already working on this.

Since Sep 9, 2026.

python workflows
Dominant language
Python
Stars
13.6k
Forks
2.3k
Avg merge
2d 45m
Merged PRs (30d)
358

Description

## Summary

Is there a supported / convenient way in Agent Framework (Python) to determine whether a given `WorkflowCheckpoint` represents a **topological end** of the workflow graph — i.e. the run has converged on a node (or set of nodes) that has **no outgoing edges**?

This is **not** about business-level “case complete” / conversation termination (e.g. handoff `termination_condition`). It is only about: *from the checkpoint + workflow graph, has execution reached a sink with nowhere left to go?*

## Context

For multi-process / multi-worker hosting we typically:

1. `workflow_id` → build a fresh `Workflow` instance
2. `checkpoint_id` → restore and continue

It would be useful to know, **before** or **after** restore, whether that checkpoint is already at a graph sink so the host can treat the run as finished (reuse vs rebuild policy, UI, etc.).

Today `WorkflowCheckpoint` exposes things like:

- `pending_request_info_events`
- `messages`
- `state` (including `_executor_state` / `_edge_state`)
- `iteration_count`, `graph_signature_hash`, `metadata`

but there does not appear to be an explicit “current executor(s)” or `is_topologically_complete` / similar API.

## What we considered

| Signal | Why it seems insufficient for *topological* end |
|---|---|
| `WorkflowRunState.IDLE` | Means this `run()` converged; common every turn in multi-turn / handoff graphs that still have outgoing edges |
| `pending_request_info_events == {}` | Means not waiting on HITL; not “no outgoing edges” |
| `WorkflowEvent.type == "output"` | Means a designated output yield; can fire many times before the graph is done |
| Infer sink via `edge_groups` + “current node” | Graph sinks are computable from `workflow.edge_groups`, but the checkpoint does not clearly record which executor is “current”, so hosts end up wrapping sink `execute` methods and writing custom `state["workflow_ended"] = True` |

## Questions for maintainers / community

1. Is there an existing recommended way to detect **topological end** from a `checkpoint_id` (optionally with the matching `Workflow` instance for `graph_signature_hash` / edges)?
2. If not, would the project consider a first-class helper, e.g.:
- recording last completed / frontier executor id(s) in checkpoint metadata, and/or
- something like `workflow.is_topologically_complete(checkpoint) -> bool` (sink reached + no in-flight messages + no pending requests)?
3. Is the intended pattern that hosts always write an explicit shared-state flag (e.g. `ctx.set_state("workflow_ended", True)` on sink executors) rather than inferring from checkpoint shape?

## Environment

- Language: Python
- Area: `agent_framework` workflows / checkpointing (`WorkflowCheckpoint`, `CheckpointStorage`)
- Related concepts: multi-worker resume via `workflow.run(checkpoint_id=...)`

Thanks!

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.