Python: foundry-hosting drops request `metadata` from the stored response — `_create_response_event_stream` never passes `request` to `ResponseEventStream`
メンテナーはふだん 1 日以内に返信
@its-amann がすでに取り組んでいます。
2026年10月19日 から。
評価
- 難易度
- 2/5
- 見積もり時間
- 1〜3時間
- 初心者へのやさしさ
- 78/100
調査の方向性
agent_framework_foundry_hosting/_responses.pyから始めて、_handle_responseから_create_response_event_streamまでを追います。issueでは、新しいレスポンスに必要なリクエスト引数が欠けていると指摘されています。ResponseEventStreamがリクエストからフィールドを設定する方法を確認し、作成されたレスポンスと保存されたレスポンスのメタデータに関する的を絞ったテストを追加または更新します。POST時のメタデータがレスポンスイベントとGET /responses/{id}で保持されれば完了です。
索引モデルが issue の本文から書いたものです。
説明
Description
When a client calls POST /responses on a ResponsesHostServer with a metadata object, that metadata is not present on the response object that is emitted (response.created / terminal events) or persisted, so GET /responses/{id} returns metadata: null.
This breaks the standard OpenAI Responses contract, where request metadata is echoed onto the response, and prevents clients from using response metadata to label/correlate turns (for example, recording per-turn settings and reading them back when listing conversation history).
Client impact (.NET SDK)
Our client is a .NET service using Azure.AI.Projects / Azure.AI.Extensions.OpenAI (2.1.0-beta.4). It sends the metadata when creating the response (CreateResponseOptions.Metadata), and when listing conversation history it reads it back per turn:
GetProjectConversationItemsAsync(conversationId)to enumerate message items (items carry no metadata, onlyResponseId).GetResponseAsync(new GetResponseOptions(responseId))and readresult.Value.Metadata.
Because the hosted agent never seeds metadata onto the response, result.Value.Metadata is always empty for responses produced by a ResponsesHostServer-hosted agent, so the .NET client has no way to recover the per-turn values it sent.
Root cause
azure-ai-agentserver-responses already supports this: ResponseEventStream(request=...) seeds metadata, background, previous_response_id, conversation, model and agent_reference from the request.
However, in agent_framework_foundry_hosting/_responses.py the stream is created without the request:
def _create_response_event_stream(context: ResponseContext) -> ResponseEventStream:
"""Create a response stream seeded from recovery state when available."""
if context.is_recovery:
persisted_response = context.persisted_response
if persisted_response is not None:
return ResponseEventStream(response=persisted_response, response_id=context.response_id)
return ResponseEventStream(response_id=context.response_id)
and ResponsesHostServer._handle_response(self, request, context, cancellation_signal) calls _create_response_event_stream(context) even though request is in scope. The same code is still present on main.
Steps to reproduce
- Host any agent or workflow with
ResponsesHostServer. POST /responseswith"metadata": {"foo": "bar"}and"store": true.- Inspect the
response.createdevent, orGET /responses/{id}.
Expected: metadata == {"foo": "bar"}
Actual: metadata is null / missing.
Suggested fix
Pass the request through for fresh (non-recovery) responses:
def _create_response_event_stream(context: ResponseContext, request: CreateResponse) -> ResponseEventStream:
if context.is_recovery:
persisted_response = context.persisted_response
if persisted_response is not None:
return ResponseEventStream(response=persisted_response, response_id=context.response_id)
return ResponseEventStream(request=request, response_id=context.response_id)
and call _create_response_event_stream(context, request) from _handle_response.
Current workaround
Monkey-patching the private agent_framework_foundry_hosting._responses._create_response_event_stream to stamp metadata onto stream.response["metadata"] before response.created is emitted. This depends on a private symbol and breaks on upgrade.
Related: #9265 (public per-request / stream-wrapping hooks).
Versions
agent-framework-foundry-hosting1.0.0b260903 (also verified onmain)agent-framework1.18.xazure-ai-agentserver-responses2.2.0b1,azure-ai-agentserver-core2.1.0- Python 3.14
- 主要言語
- Python
- スター
- 14.2k
- フォーク
- 2.5k
- 平均マージ
- 2日 9時間
- マージ済み PR(30日)
- 369
環境構築
このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
microsoft/agent-framework のほかの issue
-
Python: [Bug]: A non-positive MCP request timeout silently disables the timeout対応中かも @jpalvarezl が 9 日前に担当しました。 オープンpython
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
microsoft/agent-framework#9313 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
.NET python triage
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
microsoft/agent-framework#9092 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Python: raw-data content mappings lose annotations and attachment metadata対応中かも @moonbox3 が 22 日前に担当しました。 オープンpython triage
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
microsoft/agent-framework#8632 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
-
Python: Clarify when to use platform対応中かも @eavanvalkenburg が 22 日前に担当しました。 オープンpython triage
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
microsoft/agent-framework#8599 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
.NET compaction documentation
難易度 1/5 1時間未満 初心者へのやさしさ 82/100
microsoft/agent-framework#4629 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
microsoft/agent-framework の issue をすべて見る
似ている issue
-
[Bug]: Revit selector reads process ids 2000-2099 as years (flaky AgentClientTests.AYearOrAProcessIdSelectsTheHost)対応中かも @Wurschdhaud が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 83/100
pyrevitlabs/pyRevit#3817 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
521xueweihan/HelloGitHub#4074 ·
-
follow-up
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
メンテナーはふだん 1 日以内に返信
-
Helm chart: allow setting ingressClassName on the Ingress対応中かも @commarla が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
pgadmin-org/pgadmin4#10658 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100