Skip to content

Python: fix(core): move EdgeGroup's builtins.type alias to module scope (fixes Public API Compatibility) - #9614

Merged
Eduard van Valkenburg (eavanvalkenburg) merged 1 commit into
microsoft:mainfrom
Nanduu24:fix/edge-group-type-alias
Oct 23, 2026
Merged

Eduard van Valkenburg (eavanvalkenburg) merged 1 commit into
microsoft:mainfrom
Nanduu24:fix/edge-group-type-alias

Conversation

@Nanduu24

Copy link
Copy Markdown
Contributor

Summary

The Public API Compatibility check currently fails on PRs with:

griffe...AliasResolutionError: Could not resolve alias
agent_framework._workflows._edge.EdgeGroup.builtin_type pointing at builtins.type
(in python/packages/core/agent_framework/_workflows/_edge.py)

The cause is that from builtins import type as builtin_type is written inside the EdgeGroup class body, so builtin_type becomes a class member (EdgeGroup.builtin_type) aliasing builtins.type. griffe treats it as a public alias and errors trying to resolve it while building the API, which fails the workflow.

Fix

Move the alias to module scope, matching _workflows/_request_info_mixin.py, which already imports builtin_type at module level. The annotations that use it (_TYPE_REGISTRY: ClassVar[dict[str, builtin_type[EdgeGroup]]] and EdgeGroup.register) are unchanged and still resolve, while EdgeGroup no longer exposes a spurious builtin_type member.

This is behavior-preserving: the module uses from __future__ import annotations, and builtin_type is referenced only in annotations — nothing accesses EdgeGroup.builtin_type/self.builtin_type at runtime. (The other occurrences in _executor.py are method-local, so they are not class members and are unaffected.)

Verification

  • griffe now loads EdgeGroup cleanly — no AliasResolutionError, and no builtin_type member.
  • pyright (strict) and ruff pass on the file.

…cope

The `from builtins import type as builtin_type` import lived inside the EdgeGroup
class body, making `EdgeGroup.builtin_type` a class member aliasing builtins.type.
The Public API Compatibility workflow (griffe) raises
`AliasResolutionError: Could not resolve alias agent_framework._workflows._edge.EdgeGroup.builtin_type
pointing at builtins.type` while loading the API, which fails the check on every PR.

Move the alias to module scope (matching _request_info_mixin.py, which already does
this) so the spurious class member is gone while the annotations (builtin_type[...])
stay resolvable. No runtime or type-checker behavior change: the module uses
`from __future__ import annotations`, and builtin_type is referenced only in
annotations. Verified griffe loads EdgeGroup cleanly; pyright and ruff pass.
@Nanduu24

Copy link
Copy Markdown
Contributor Author

Note for whoever merges: the failing Public API Compatibility check here is the very bug this PR fixes, observed from the base side. griffe's find_breaking_changes(old_package, new_package) loads the old (base) API first and raises AliasResolutionError: ...EdgeGroup.builtin_type pointing at builtins.type on the pre-fix _edge.py:315, so the check can't pass until the fix is on main. The head/new API in this PR resolves cleanly (verified with griffe + pyright + ruff). It should need an admin merge / override of that one check, after which the check goes green here and on every other open PR.

Merged via the queue into microsoft:main with commit 3b725b3 Oct 23, 2026
52 of 54 checks passed
Yousuf alkhanjari (ghox789) added a commit to ghox789/agent-framework that referenced this pull request Oct 23, 2026
Bring the PR branch up to date with upstream main so CI re-runs against
current base (clears the Public API Compatibility failure fixed upstream in
microsoft#9614 and the merge-gatekeeper BEHIND state). No changes to the fix itself.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BhP294P7bydCU9UZxwrohh

This branch was successfully deployed

1 active deployment
github-app-auth — e7a7ad76 Deployed Oct 22, 2026 by Nanduu24 via team_check #7291
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

python Usage: [Issues, PRs], Target: Python

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants