Skip to content

Python: Preserve provider error responses in hosting - #9665

Open
Roger Barreto (rogerbarreto) wants to merge 4 commits into
microsoft:mainfrom
rogerbarreto:i798-hosting-errors
Open

Roger Barreto (rogerbarreto) wants to merge 4 commits into
microsoft:mainfrom
rogerbarreto:i798-hosting-errors

Conversation

@rogerbarreto

@rogerbarreto Roger Barreto (rogerbarreto) commented Oct 24, 2026 •

Copy link
Copy Markdown
Member

Motivation & Context

Provider HTTP errors can contain structured error titles, messages, and correlation fields that callers need for diagnostics and handling. The Python Responses hosting paths previously replaced these details with generic classifications or messages, losing distinctions such as DeploymentNotFound and missing_required_parameter.

This change preserves the original SDK error already carried by ChatClientException when converting chat-client failures into response.failed, while retaining the existing generic sanitization for unexpected local failures.

Description & Review Guide

  • What are the major changes?
    • Keep provider-specific handling entirely inside agent-framework-hosting-responses and agent-framework-foundry-hosting; core and connector packages are unchanged.
    • Unwrap one standard ChatClientException boundary through its existing __cause__/inner_exception reference.
    • Copy the SDK's existing code, message, status_code, and body fields without interpreting the provider body or inferring classifications from HTTP status.
    • Preserve fields such as type, param, and Projects request_id in response.failed.
    • Keep vetted backend-authored messages and the existing generic fallback for non-chat-client or malformed failures.
  • What is the impact of these changes?
  • What do you want reviewers to focus on?
    • Whether unwrapping exactly one ChatClientException boundary is the correct trust boundary.
    • The body-copy behavior: server fields win, SDK attributes are fallback only, and malformed access fails closed.
    • Compatibility with the sanitization behavior from Python: Sanitize unexpected streaming response failures #9460.

Related Issue

N/A - internally tracked reliability correction. The originating report is not tracked in a public GitHub issue. The adjacent generic sanitization work in #9460 is already merged and is preserved by this change.

AI Assistance

  • No material AI assistance was used.
  • This is an AI-assisted contribution. I reviewed, understood, and verified all submitted content and accept responsibility for it.

AI assistance details: Implementation, tests, documentation, live contract validation, and PR description.

Contribution Checklist

  • The code builds clean without any errors or warnings
  • All unit tests pass, and I have added new tests where possible
  • The PR follows the Contribution Guidelines
  • This PR links to an agreed issue with no competing open PR, or the Related Issue section documents a trivial-change or repository-automation exception.
  • This is not a breaking change. If it is a breaking change, add the breaking change label (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow keeps the label and the title prefix in sync automatically.

Use structured provider body codes and messages instead of inferring error titles from HTTP status when rendering response.failed events.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

Rendered exception text can bypass sanitization, dependency bounds permit import failures, and non-string fields can suppress valid provider fallbacks.

3 open issues
What changed in this PR

This PR centralizes provider-error extraction for both Python Responses hosting integrations, preserving provider-defined codes and messages while aiming to retain the sanitization introduced in #9460.

Changes:

  • Adds a shared classifier for structured provider errors and framework exception wrappers.
  • Integrates provider details into failed-response serialization, including arbitrary error codes.
  • Adds regression tests, documents error disclosure behavior, and raises the hosting-responses core dependency minimum.
File Description
python/​packages/​hosting-responses/​tests/​hosting_responses/​test_parsing.py Tests streamed provider failures and exception wrappers.
python/​packages/​hosting-responses/​README.md Documents provider-error preservation and disclosure ownership.
python/​packages/​hosting-responses/​pyproject.toml Raises the core dependency minimum.
python/​packages/​hosting-responses/​agent_framework_hosting_responses/​_parsing.py Applies shared extraction and preserves arbitrary serialized codes.
python/​packages/​foundry_hosting/​tests/​test_responses.py Tests provider details in terminal failure events.
python/​packages/​foundry_hosting/​README.md Documents error-field precedence and disclosure ownership.
python/​packages/​foundry_hosting/​agent_framework_foundry_hosting/​_responses.py Integrates extraction while retaining vetted validation messages.
python/​packages/​core/​tests/​core/​test_exceptions.py Adds extraction, fallback, and wrapper-boundary tests.
python/​packages/​core/​agent_framework/​exceptions.py Implements shared provider-error extraction.

Review effort: Balanced

Comment thread python/packages/core/agent_framework/exceptions.py Outdated
Comment thread python/packages/hosting-responses/pyproject.toml Outdated
Comment thread python/packages/core/agent_framework/exceptions.py Outdated

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MAF Automated Review — Iteration 1

Result: Findings reported
Scope: full PR (1 commit(s)): 659a0e2deafc
Model: gpt-5.6-sol

Overview

The PR centralizes provider-error extraction and applies it consistently to both Responses hosting paths, with useful tests for framework wrappers, cycles, unsupported statuses, and ordinary exception sanitization. However, the declared core floor does not contain the new helper, and the generic hosting path deliberately emits error codes outside the Responses schema. The classifier also trusts HTTP-shaped local exceptions and can itself raise while handling an error, leaving meaningful disclosure and terminal-stream risks.

Reviewed the supplied pull-request change set across correctness, security/reliability, architecture, and failure behavior.
4 verified findings remained after source verification (2 high, 2 medium) across 3 files. Details are attached to the affected lines below.

Affected areas: python/packages/core/agent_framework/exceptions.py, python/packages/hosting-responses/agent_framework_hosting_responses/_parsing.py, python/packages/hosting-responses/pyproject.toml

Comment thread python/packages/hosting-responses/pyproject.toml Outdated
Comment thread python/packages/hosting-responses/agent_framework_hosting_responses/_parsing.py Outdated
Comment thread python/packages/core/agent_framework/exceptions.py Outdated
Comment thread python/packages/core/agent_framework/exceptions.py Outdated
Attach provider-neutral error details when connectors translate SDK failures so hosting never inspects provider exception bodies.
Reuse the original SDK exception already carried by ChatClientException and keep provider-specific handling out of core and connectors.
@rogerbarreto

Copy link
Copy Markdown
Member Author

/review

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MAF Automated Review — Iteration 2

Result: Findings reported
Scope: 2 net-new commit(s): 86bd846b9def, 0cbec8e8d90a
Model: gpt-5.6-sol

Overview

The change narrows provider-error disclosure to the SDK exception carried by ChatClientException, retains sanitized fallbacks, and adds coverage for standard cause chains and primitive provider fields. Property access and malformed effective code/message values fail closed. One residual serialization gap can still replace the intended terminal failure event with a second exception when a provider body contains a non-JSON value.

Reviewed the supplied incremental change set across correctness, security/reliability, architecture, and failure behavior.
1 verified finding remained after source verification (1 medium) across 1 file. Details are attached to the affected lines below.

Affected areas: python/packages/hosting-responses/agent_framework_hosting_responses/_parsing.py

Fail closed to the sanitized terminal error when a provider body contains non-JSON values or cycles.

This branch was successfully deployed

1 active deployment
github-app-auth — 89be748b Deployed Oct 24, 2026 by rogerbarreto via add_label #26083
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Usage: [Issues, PRs], Target: documentation in the code base and learn docs python Usage: [Issues, PRs], Target: Python

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants