Repository navigation
Description
I am using AgentSession to persist and restore workflow execution state in Python. The scenario that fails is Magentic orchestration with human plan review enabled.
When the workflow pauses for human plan review, the SSE stream emits a request_id. I persist the session state, including the pending request metadata, and then try to resume the same session by sending feedback for that same request_id. The session does not resume the pending request and instead errors.
Expected behavior :
If a session pauses on request_info and I restore that same AgentSession later, responding with the same request_id should resume execution successfully.
Question :
How should pending requests in AgentSession be handled after restoring a persisted session? Specifically, if human plan review in Magentic generates a request_id and that pending request is saved in session state, what is the correct way to resume it later using the same request_id?
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsIn Progress
Activity
github-actions commentedon May 26, 2026
🤖 Automated triage reproduction notes (agent-authored — trust but verify)
Agent analysis
Repro: WorkflowAgent._pending_requests (python/packages/core/agent_framework/_workflows/_agent.py:131) is not captured by AgentSession.to_dict() (python/packages/core/agent_framework/_sessions.py:744-756). When _run_core() at line 422 checks bool(self.pending_requests) after session restore on a new agent, it finds empty dict and falls to the else branch (line 466) starting a fresh run instead of resuming. Minimal repro: create WorkflowAgent with a RequestingExecutor, run until request_info emitted, serialize session with to_dict(), create new agent, restore session with from_dict(), and attempt to send approval response for the original request_id — workflow starts fresh instead of resuming.
python/packages/core/tests/workflow/test_issue_5818_session_pending_request_resume.py1.6.0TaoChenOSU commentedon May 27, 2026
Pending requests are persisted in checkpoints rather than sessions. Evan Mattson (@moonbox3) should we hide the workflow related abstractions such as checkpoints in workflows as agents?
GeekeRahul commentedon Jun 16, 2026
Tao Chen (@TaoChenOSU) Hi team, following up on this issue for an update.
Could you share current status and expected timeline for a fix?
TaoChenOSU commentedon Jun 24, 2026
Hi, GeekeRahul,
Folding the checkpoint into the agent session will likely require a bigger change and we are still evaluating it. For now, please use checkpoint instead.
HarperZ9 commentedon Jul 21, 2026
Since the current guidance is to persist and resume through the checkpoint, would a small conformance fixture around that contract be useful before the larger
AgentSessiondesign decision?I can contribute an offline, no-model test that records a structural receipt across
pause -> persist checkpoint -> construct a fresh agent/workflow -> restore -> respondand asserts:request_idresume exactly one pending request;The fixture would store only IDs, digests, checkpoint metadata, and event types—no model output or raw request payload—and it would not claim exactly-once behavior for external tool side effects. If that matches the intended checkpoint semantics, I’m happy to prepare a narrow test-only PR; otherwise I’ll leave the scope here.
GeekeRahul commentedon Jul 28, 2026
Hi Tao Chen (@TaoChenOSU) , is there any update on AgentSession and do we have any planned timeline? We are currently moving forward with checkpoint approach.