Python: [Bug]: Orphaned mcp_call items cause HTTP 400 in multi-turn reasoning model flows

[csajmishra]

Description

Problem highlighted in below issue has not been resolved for customer.
#6074

Code Sample

Attached the code sample used by client. 
[run_maf_workflow.txt](https://github.com/user-attachments/files/29597439/run_maf_workflow.txt)
[run_workflow.txt](https://github.com/user-attachments/files/29597438/run_workflow.txt)

Error Messages / Stack Traces

HTTP 400 — Item 'mcp_<id>' of type 'mcp_call' was provided without its
required 'reasoning' item: 'rs_<id>'.

Package Versions

agent-framework==1.8.0

Python Version

3.13

Additional Context

Issue is INTERMITTENT — does not fire on every run. We need to try 5-6 times to reproduce.

[github-actions]

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

Agent analysis

Repro: SlidingWindowStrategy in packages/core/agent_framework/_compaction.py orphans mcp_call from reasoning because (1) _output_item_to_message in packages/foundry_hosting/.../_responses.py:1381-1386 converts reasoning OutputItems via Content.from_text() instead of Content.from_text_reasoning(), and (2) _is_tool_call_assistant at _compaction.py:78 only checks for "function_call" not "mcp_server_tool_call". Minimal repro: annotate_message_groups on [system, assistant(text="Reasoning"), assistant(mcp_server_tool_call), tool(result), assistant(text), user] then apply SlidingWindowStrategy(keep_last_groups=4) — reasoning is removed while mcp_call remains.

• Failing test: python/packages/core/tests/core/test_orphaned_mcp_call_issue_6883.py
• Files examined: python/packages/core/agent_framework/_compaction.py, python/packages/foundry_hosting/agent_framework_foundry_hosting/_responses.py, python/packages/core/agent_framework/_types.py, python/packages/foundry_hosting/tests/test_responses.py, python/packages/core/tests/core/test_compaction.py
• Tests run: python/packages/core/tests/core/test_orphaned_mcp_call_issue_6883.py
• Reported version: 1.8.0
• Current version: 1.10.0

[Tuttotorna]

This looks like a reasoning-item / MCP-call pairing boundary issue.

The key distinction is:

mcp_call item present
!=
transcript state valid for the next provider request

From the issue, the provider rejects the transcript because it contains:

mcp_call: mcp_

without the required paired reasoning item:

reasoning: rs_

So the failure is not only that an HTTP 400 occurs downstream.

The framework is allowing an incomplete provider-state pair to cross the request boundary.

The failing transition is:

reasoning model emits reasoning item
→ MCP call item is created
→ framework persists / reconstructs transcript
→ next provider request is built
→ every mcp_call must still be paired with its required reasoning item

But the observed state is:

mcp_call survives
required reasoning item missing
next request sent anyway
provider rejects with 400

A minimal conformance fixture could be:

case_1:
transcript_contains_mcp_call: true
paired_reasoning_item_present: false
next_provider_request_sent: true
expected: NON_CONFORMANT
reason: orphaned mcp_call crossed the provider request boundary

case_2:
transcript_contains_mcp_call: true
paired_reasoning_item_present: false
request_builder_blocks_locally: true
expected: HARD_BLOCK_OR_REPAIR
reason: invalid transcript state must be caught before provider call

case_3:
transcript_contains_mcp_call: true
paired_reasoning_item_present: true
mcp_call_reasoning_ref_matches: true
expected: CONFORMANT

case_4:
transcript_contains_reasoning_item: true
transcript_contains_mcp_call: true
reasoning_item_removed_during_compaction: true
mcp_call_retained: true
expected: NON_CONFORMANT
reason: compaction must preserve paired provider-required items atomically

case_5:
transcript_contains_mcp_call: true
paired_reasoning_item_missing: true
repair_synthesizes_reasoning_item: false
repair_removes_orphans_before_request: true
expected: REPAIR_OK

case_6:
transcript_contains_mcp_call: true
paired_reasoning_item_missing: true
repair_policy_unknown: true
expected: HARD_BLOCK
reason: framework must not guess provider-required reasoning state

The invariant I would preserve is:

provider-required transcript pairs must be persisted, compacted,
replayed, and emitted atomically.

So an mcp_call should not be treated as an independent transcript item if the provider contract requires a paired reasoning item.

The state model probably needs an explicit pair boundary:

reasoning_item_id
mcp_call_id
pair_id
pair_complete: true
persistence_epoch
compaction_policy
request_emit_status

Then the request builder can enforce:

for every mcp_call in the outgoing transcript:
required reasoning item exists
pair id matches
both items survived compaction/replay
or the pair is repaired/removed before the provider request

Otherwise the framework has two incompatible states:

local state:
transcript appears reconstructable

provider state:
transcript violates required reasoning/MCP pairing

The important point is that this should fail locally as a repairable transcript-integrity error, not remotely as a provider 400.

This is a transition-sufficiency issue:

the next provider-request transition is treated as valid,
but the support required to prove every MCP call is paired with its required reasoning item
is missing from the reconstructed transcript.

Technical signature:
Result produced by the PHI-OMEGA algorithm — transition-sufficiency analysis:
Required(τ) ⊆ Supported(τ)