Foundry chat clients leak aiohttp sessions across agent runs

[TsuyoshiUshio]

Please provide us with the following information:

This issue is for a: (mark with an x)

- [x] bug report -> please search issues before submitting
- [ ] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

1. Configure an agent app with AZURE_FUNCTIONS_AGENTS_PROVIDER=foundry, FOUNDRY_PROJECT_ENDPOINT, and a Foundry model.
2. Run the app with func start.
3. Execute one or more agent turns. The samples/per-agent-workflows scenario also reproduces this after primary and Workflow Sub Agent calls complete successfully.
4. Stop the Functions host.

The current ownership path is:

• runner._build_agent_session_history() calls ClientManager.build_chat_client_with_target() for every primary run.
• runner._build_delegated_agent() does the same for every delegated/Workflow Sub Agent run.
• MAFClientManager._build_foundry() constructs a fresh FoundryChatClient with a fresh async credential.
• Agent Framework 1.3.0 internally constructs and stores an async AIProjectClient; that client exposes async close() and owns an aiohttp.ClientSession.
• The runtime does not retain or close the generated chat/project clients. MAFClientManager inherits the no-op ClientManager.close() implementation.
• shutdown_client_manager() exists but has no production caller, and would not close these untracked resources even if called.

Any log messages given by the failure

Unclosed client session
client_session: <aiohttp.client.ClientSession object at 0x...>

The agent/workflow result itself can still complete successfully before this warning is emitted.

Expected/desired behavior

Foundry HTTP transports and async credentials should have an explicit owner and be closed deterministically. No Unclosed client session warning should appear after successful, failed, timed-out, canceled, or streaming agent execution, including delegated and Workflow Sub Agent calls.

Suggested acceptance criteria:

• Define whether provider resources are per-run or process-wide and track them accordingly.
• Close Foundry AIProjectClient/transport and owned async credentials exactly once.
• Cover non-streaming success/error/timeout/cancellation and streaming completion/disconnect paths.
• Ensure any process-wide shutdown API is actually wired into the runtime lifecycle.
• Add tests that fail when a generated provider resource is not closed.

OS and Version?

Windows_NT, Azure Functions Core Tools 4.10.0, Functions runtime 4.1048.200.26180.

Versions

• Python 3.13.15
• agent-framework-foundry 1.3.0
• azure-ai-projects 2.3.0
• aiohttp 3.14.3

Mention any other details that might be useful

This is not specific to Dynamic Workflow drain mode. Workflows with Sub Agents make the leak more visible because both coordinator and specialist execution construct fresh Foundry clients. Repeated turns in a long-lived worker may accumulate transports before process shutdown, so this should not be treated only as cosmetic shutdown logging.

---

Thanks! We'll be in touch soon.