Skip to content

Python: fix: prevent inner_exception from being lost in AgentFrameworkException#5167

Merged
moonbox3 merged 3 commits intomicrosoft:mainfrom
Bahtya:fix/exception-inner-exception-lost
Apr 27, 2026
Merged

Python: fix: prevent inner_exception from being lost in AgentFrameworkException#5167
moonbox3 merged 3 commits intomicrosoft:mainfrom
Bahtya:fix/exception-inner-exception-lost

Conversation

@Bahtya
Copy link
Copy Markdown
Contributor

@Bahtya Bahtya commented Apr 8, 2026

Problem

AgentFrameworkException.__init__() unconditionally calls super().__init__(message, *args) after the conditional super().__init__(message, inner_exception, *args). When inner_exception is provided, the second call overwrites the exception args, losing the inner exception reference.

Root Cause

Missing else branch — both super().__init__() calls execute when inner_exception is truthy.

Fix

Add else: branch so super().__init__() is called exactly once with the correct arguments.

Before:

if inner_exception:
    super().__init__(message, inner_exception, *args)
super().__init__(message, *args)  # always runs, overwrites args

After:

if inner_exception:
    super().__init__(message, inner_exception, *args)
else:
    super().__init__(message, *args)

Fixes #5155

The __init__ method unconditionally called super().__init__() after
the conditional call with inner_exception, effectively overwriting the
exception args and losing the inner_exception reference.

Add else branch so super().__init__() is only called once with the
correct arguments.

Fixes microsoft#5155

Signed-off-by: bahtya <bahtyar153@qq.com>
@moonbox3 moonbox3 added the python label Apr 8, 2026
@github-actions github-actions Bot changed the title fix: prevent inner_exception from being lost in AgentFrameworkException Python: fix: prevent inner_exception from being lost in AgentFrameworkException Apr 8, 2026
@Bahtya
Copy link
Copy Markdown
Contributor Author

Bahtya commented Apr 11, 2026

Hi team, just wanted to follow up on this PR. It has been approved by @eavanvalkenburg. There appear to be some CI failures — happy to investigate if they're related to this change. Would appreciate any feedback!

…handling

- test_exception_with_inner_exception: verifies args include inner exception
- test_exception_without_inner_exception: verifies args only contain message
- test_exception_inner_exception_none_explicit: verifies explicit None

Covers both branches of the if/else in __init__.
@Bahtya
Copy link
Copy Markdown
Contributor Author

Bahtya commented Apr 13, 2026

CI Failure Analysis

The Python 3.11 test failures are not caused by this PR. They are pre-existing issues in the durabletask package:

TypeError: argument of type 'Mock' is not iterable
durabletask/entities/entity_instance_id.py:83

This error occurs in EntityInstanceId.__init__ when a Mock object is passed as entity_key — the if not entity_key check fails because Mock is not iterable on Python 3.11.

I have added explicit unit tests for the AgentFrameworkException inner_exception handling in python/packages/core/tests/core/test_exceptions.py to ensure both code branches are covered.

The coverage and merge-gatekeeper failures are downstream of the Python 3.11 test failure.

@Bahtya
Copy link
Copy Markdown
Contributor Author

Bahtya commented Apr 18, 2026

@microsoft-github-policy-service agree

@moonbox3
Copy link
Copy Markdown
Contributor

@Bahtya please fix the CI/CD failures

@Bahtya
Copy link
Copy Markdown
Contributor Author

Bahtya commented Apr 27, 2026

@moonbox3 The CI workflows (Python - Tests, Code Quality, etc.) are stuck at action_required status — they require maintainer approval to trigger for fork PRs. The previous test failure from April 13 was a pre-existing issue in the durabletask package (TypeError: argument of type 'Mock' is not iterable on Python 3.11), not related to this PR. Could a maintainer approve the CI workflow runs so we can verify the latest commit?

@moonbox3
Copy link
Copy Markdown
Contributor

@moonbox3 The CI workflows (Python - Tests, Code Quality, etc.) are stuck at action_required status — they require maintainer approval to trigger for fork PRs. The previous test failure from April 13 was a pre-existing issue in the durabletask package (TypeError: argument of type 'Mock' is not iterable on Python 3.11), not related to this PR. Could a maintainer approve the CI workflow runs so we can verify the latest commit?

Yes, CI/CD checks require approval. But all checks can also be run locally. If they pass locally, they will pass when pushed to origin/upstream.

image

@moonbox3
Copy link
Copy Markdown
Contributor

Python Test Coverage

Python Test Coverage Report •
FileStmtsMissCoverMissing
packages/core/agent_framework
   exceptions.py660100% 
TOTAL29865347988% 

Python Unit Test Overview

Tests Skipped Failures Errors Time
6026 30 💤 0 ❌ 0 🔥 1m 39s ⏱️

@moonbox3 moonbox3 added this pull request to the merge queue Apr 27, 2026
Merged via the queue into microsoft:main with commit dad3652 Apr 27, 2026
32 checks passed
moonbox3 added a commit to moonbox3/agent-framework that referenced this pull request Apr 28, 2026
PATCH bump (1.2.0 -> 1.2.1) for the released cohort. The release window
covers two PRs, no new public APIs:

- agent-framework-core: prevent inner_exception from being lost in
  AgentFrameworkException (microsoft#5167)
- samples: add requirements.txt and .env.example to the a2a/ hosting
  sample for pip-based setup (microsoft#5510)

Per lockstep convention, all 21 beta packages stamp 1.0.0b260428 and all
3 alpha packages stamp 1.0.0a260428, regardless of per-package code
churn. Every non-core package floor on agent-framework-core is raised to
>=1.2.1 to keep cohort signaling consistent. Date stamp reflects the
local (Asia) cut date 2026-04-28.
moonbox3 added a commit that referenced this pull request Apr 28, 2026
* Python: bump package versions for 1.2.1 release

PATCH bump (1.2.0 -> 1.2.1) for the released cohort. The release window
covers two PRs, no new public APIs:

- agent-framework-core: prevent inner_exception from being lost in
  AgentFrameworkException (#5167)
- samples: add requirements.txt and .env.example to the a2a/ hosting
  sample for pip-based setup (#5510)

Per lockstep convention, all 21 beta packages stamp 1.0.0b260428 and all
3 alpha packages stamp 1.0.0a260428, regardless of per-package code
churn. Every non-core package floor on agent-framework-core is raised to
>=1.2.1 to keep cohort signaling consistent. Date stamp reflects the
local (Asia) cut date 2026-04-28.

* Python: silence pyright unknown-type warnings in hosted-env detection

`azure.ai.agentserver.core` is probed at runtime via `importlib.util.find_spec`
and is not a declared dependency. The existing `# pyright: ignore[reportMissingImports]`
suppresses the missing-import warning, but at `lowest-direct` resolution pyright
still reports the imported symbol (`AgentConfig`) and its members (`from_env`,
`is_hosted`) as unknown, breaking `validate-dependency-bounds-test` for
`packages/core`.

Extend the existing ignore to cover `reportUnknownVariableType` on the import
and `reportUnknownMemberType` on the call site so the bounds check returns to
green. Behavior is unchanged.

Latent since #5455 (shipped in 1.2.0).

* Python: raise agent-framework-gemini lower bound to google-genai>=1.65.0

The Gemini chat client references several `google.genai.types` symbols
(`FileSearch`, `ThinkingLevel`, `SearchTypes`, `McpServer`,
`StreamableHttpTransport`, plus call-site keyword args `mcp_servers` and
`search_types`) that are not present at the lower bound of `google-genai>=1.0.0`.
At `lowest-direct` resolution this caused `validate-dependency-bounds-test` to
fail for `packages/gemini` with eleven `reportAttributeAccessIssue` /
`reportUnknownVariableType` errors.

Walking the upstream `google.genai.types` API:
- `GoogleMaps`, `AuthConfig`: present from 1.40.0
- `FileSearch`: introduced in 1.49.0
- `ThinkingLevel`: introduced in 1.55.0
- `SearchTypes`, `McpServer`, `StreamableHttpTransport`: introduced in 1.65.0

Bump the lower bound to 1.65.0 — the minimum version that exposes every symbol
the package actually uses. Keep the `<2.0.0` upper cap unchanged. With this
bump `validate-dependency-bounds-test` passes for both lower and upper
resolution scenarios across all 27 workspace packages.

Latent since #4847 (Gemini package introduction in 1.1.0); aggravated by
subsequent feature additions that pulled in newer `types.*` symbols.

* Python: add dependabot bumps to 1.2.1 CHANGELOG

Catalog the 15 dependabot dependency updates that merged on `upstream/main`
between python-1.2.0 and the 1.2.1 cut window under a new Changed section:

- Workspace dev/runtime deps: `rich`, `prek`, `python-multipart`, `pyasn1`,
  `pytest` (ag-ui, devui, lab), `uv` (lab)
- Frontend deps: `vite` (devui, chatkit), `postcss` (devui, chatkit, handoff),
  `picomatch` (devui, handoff)

CHANGELOG-only — no source or pyproject.toml changes. PRs themselves merged
upstream independently of this release branch and will be brought in via the
PR merge.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Python: [Bug]: "inner_exception" Information will be lost.

3 participants