Skip to content

[High] Reliability: Fix parent chat failure state after unmapped Copilot subagent errors - #348415

Open
Hazem Ali (DrHazemAli) wants to merge 1 commit into
microsoft:mainfrom
DrHazemAli:fix/subagent-error-parent-state
Open

Hazem Ali (DrHazemAli) wants to merge 1 commit into
microsoft:mainfrom
DrHazemAli:fix/subagent-error-parent-state

Conversation

@DrHazemAli

Copy link
Copy Markdown

This contribution focuses on improving the accuracy and reliability of agent execution-state reporting, particularly when errors occur during subagent execution.

The patch addresses an error-routing path that could incorrectly mark the parent conversation as failed while the underlying SDK execution continued.

Background

I encountered this issue while using BYOK for my main agent.

The main agent delegated work to a subagent using a Copilot subscription model.
The subagent encountered an error after my premium request allowance was exhausted.

The conversation displayed a red failure indicator, but the main BYOK agent continued running and making API requests. I subsequently received a substantial unexpected BYOK bill.

This experience prompted me to examine how errors are attributed and how the Agent Host manages the parent conversation's execution state.

When an agent is still executing and consuming paid resources, the conversation should accurately reflect its execution state.

Root cause

Source review identified an error-routing path in the Agent Host that could cause this mismatch.

When a session.error event includes an agentId, the handler attempts to resolve the SDK agent ID to a child tool-call ID.

If no mapping exists, parentToolCallId is undefined.

Previously, an unmapped child error could fall through to the root error path, causing the handler to:

  • Emit a ChatError to the parent conversation.
  • Finalize root failure accounting.
  • Clear the active root turn.

Clearing the Agent Host's turn state does not necessarily cancel the underlying SDK execution. Consequently, the parent conversation could appear failed while its agent continued running.

Mapped child errors could also incorrectly finalize root tool-call failure accounting.

What this changes

The patch applies the existing _shouldDropUnmappedSubagentEvent guard to session.error handling, preserving the distinction between root and child errors.

  • Mapped child errors remain associated with their corresponding child tool calls.
  • Unmapped child errors remain in logging and structured telemetry without incorrectly affecting the parent's conversation state.
  • Root errors continue through the existing root failure handling.

Root failure accounting now runs only for root errors.

flowchart TD
    A["SDK reports an error"] --> B{"Error belongs to a child?"}
    B -- No --> C["Handle root failure"]
    B -- Yes --> D{"Child mapping exists?"}
    D -- Yes --> E["Route error to child"]
    D -- No --> F["Retain diagnostics"]
    E --> G["Preserve parent turn"]
    F --> G
    G --> H["Parent continues to its own completion or failure"]
Loading

Applied Fix

The implementation makes two targeted changes in copilotAgentSession.ts:

  1. Applies _shouldDropUnmappedSubagentEvent before emitting chat errors or changing the active turn state.
  2. Restricts _reportToolCallDetails, MCP usage failure completion, and local model attribution to root errors.

The existing error logging and structured telemetry are preserved.

The patch also documents the intended error-routing behavior in AGENTS.md.

Test command:

./scripts/test.sh --run src/vs/platform/agentHost/test/node/copilotAgentSession.test.ts

Scope and limitations

This change addresses the identified error-routing and root failure-accounting behavior.

It does not modify subagent model selection, billing-provider inheritance, SDK execution cancellation, or billing enforcement.

The billing experience described above provides the background for the investigation; the patch specifically addresses the execution-state reporting issue identified during source review.

Review

I would appreciate a review of the error-routing change, particularly whether other SDK error paths or authentication-related side effects require similar protection.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant