Python: AgentExecutor keeps service_session_id when replaying full conversation

[moonbox3]

Description

AgentExecutor keeps session.service_session_id when a downstream executor is invoked with a replayed full conversation (including prior function-call/tool-result items).

This can cause provider calls to include both:

• a server-side continuation pointer (previous_response_id via service_session_id), and
• the same historical items explicitly in input.

Expected behavior: when full conversation is explicitly replayed to an agent executor, service_session_id should be cleared/reset before agent.run(...).

Steps To Reproduce

1. Run:

   pytest packages/core/tests/workflow/test_full_conversation.py::test_run_request_with_full_history_clears_service_session_id --runxfail -q

2. Observe assertion failure that the downstream spy agent still sees resp_PREVIOUS_RUN.

Code Sample

# Existing repro in repo:
# packages/core/tests/workflow/test_full_conversation.py
# test_run_request_with_full_history_clears_service_session_id

Error Messages / Stack Traces

E       AssertionError: assert 'resp_PREVIOUS_RUN' is None
E        +  where 'resp_PREVIOUS_RUN' = <...>._captured_service_session_id

Package Versions

• agent-framework-core: 1.0.0rc2
• agent-framework-orchestrations: 1.0.0b260225
• Source commit tested: 02ba27493 (main)

Python Version

Python 3.13.5

Additional Context

Likely area:

• packages/core/agent_framework/_workflows/_agent_executor.py (from_response, _run_agent*)

Related xfail note in test references issue #4047.

[github-actions]

🤖 Automated triage reproduction notes (agent-authored — trust but verify)

Agent analysis

Repro: AgentExecutor.run() in python/packages/core/agent_framework/_workflows/_agent_executor.py (line 197-211) does not clear self._session.service_session_id before calling _run_agent_and_emit() when it receives an AgentExecutorRequest containing replayed full conversation history. Minimal repro: set service_session_id on an AgentExecutor's _session, then send it an AgentExecutorRequest with full prior messages including function-call items — the agent.run() call at line 425-431 receives the stale session with the old service_session_id. Run the existing xfail test with --runxfail to confirm.

• Failing test: python/packages/core/tests/workflow/test_full_conversation.py::test_run_request_with_full_history_clears_service_session_id
• Files examined: python/packages/core/agent_framework/_workflows/_agent_executor.py, python/packages/core/tests/workflow/test_full_conversation.py
• Tests run: packages/core/tests/workflow/test_full_conversation.py::test_run_request_with_full_history_clears_service_session_id
• Reported version: 1.0.0rc2
• Current version: 1.12.0

[hxaxd]

I reproduced this with the existing workflow regression. AgentExecutor.run() replays the explicit function-call history while retaining the previous service_session_id, so the agent receives two competing sources of conversation continuity.

I'd like to submit a PR that clears service_session_id only when an AgentExecutorRequest contains function-call or function-result items, while leaving the from_response continuation path unchanged. The existing strict-xfail regression and its preservation check would become regular passing tests.

Would you be open to a PR with this approach?

[Ricky-7-Yan]

Current main still carries the strict xfail regression and I don't see a linked PR. I'd like to pick this up with a narrow executor-layer fix: clear service_session_id only when AgentExecutorRequest contains explicit function-call/function-result history, while preserving it for ordinary request messages and the from_response continuation path. I'll turn the existing xfail into a passing regression and add a preservation test. If someone is actively working on this, please let me know.

[uuzzrm]

Picking this up. Put up a fix in #7682 that clears service_session_id whenever an AgentExecutor is handed an explicit full-history replay (run/from_str/from_message/from_messages). Plain new user turns and from_response() keep the pointer, so multi-turn continuation via previous_response_id still works.