[cunninghamcard-bit]

Summary

Fixes the 3 behaviour differences in the OpenAI code that Azure reuses, found while porting the upstream Azure tests. Each difference is its own commit (listed below) and adds a test that fails on master and a CHANGELOG Fixed entry. They were separate PRs (#321, #322 and this one). To keep one fix PR per vendor, the others are closed and this PR carries all of them. The Azure test PR (#324) stacks on this branch. Part of the #276 list.

#	Commit	Difference	Was
1	cc72496c	OpenAI file search sends max_num_results as an integer	#321
2	595eedc2	OpenAI Responses stream reports a null response id	#322
3	5d54de30	OpenAI Responses reasoning deltas carry the item id	#323

1. OpenAI file search sends max_num_results as an integer

Before: the typed OpenAI file search factory (openai::tools::file_search, and provider.tools.file_search on OpenAI and Azure) took max_num_results as an f64, so maxNumResults: 5 went out on the wire as "max_num_results": 5.0.

After: as in @ai-sdk/openai 4.0.83, it goes out as 5. FileSearchArgs::max_num_results is an Option<u32>; partial_images and output_compression in the same file are integers already.

Found while porting the upstream Azure tests (cases responses › doGenerate › file search tool › … › should send request body with tool and should send include provider option for file search results).

How it works today

openai::tools::file_search(FileSearchArgs { max_num_results: Option<f64>, .. })   aimux-providers/src/openai/tools.rs:199
└─ provider_tool("file_search", args) → serde_json::to_value → { "maxNumResults": 5.0 }   tools.rs:557
OpenAIResponsesLanguageModel::do_generate / do_stream
└─ prepare_responses_tools → provider tool "file_search"
   └─ copies maxNumResults → max_num_results as is                                   responses/convert.rs:1254
      → body.tools[0].max_num_results = 5.0      ← upstream: z.number() (tool/file-search.ts:29), sent as is
                                                   (openai-responses-prepare-tools.ts:219) → 5

What this PR changes

pub max_num_results: Option<u32>,      tools.rs:199   (was Option<f64>)

Tests (tests/openai_upstream_e2e_test.rs): file_search_sends_max_num_results_as_an_integer deserializes {"vectorStoreIds":["vs_1"],"maxNumResults":5} into FileSearchArgs and checks the request body; on master it fails with left: Number(5.0), right: Number(5). The upstream cases are ported in the Azure test PR.

Docs: CHANGELOG Fixed.

Note: The field type change is source-breaking for Rust code that wrote Some(5.0); nothing in the workspace or the bindings constructs FileSearchArgs, and JSON callers that send 5 are unchanged.

2. OpenAI Responses stream reports a null response id

Before: an OpenAI or Azure Responses stream that never received response.created finished with providerMetadata.<key>.responseId: "".

After: as in @ai-sdk/openai 4.0.83, it finishes with responseId: null. The generate path already wrote null for a missing id.

Found while porting the upstream Azure tests (case responses › doStream › should handle file_citation annotations without optional fields in streaming).

How it works today

OpenAIResponsesLanguageModel::do_stream
└─ ResponsesStreamTransformer
   ├─ "response.created" → response_id = response.id                 aimux-providers/src/openai/responses/responses_convert.rs:740
   └─ flush → Finish { provider_metadata: { <key>: { responseId: response_id.unwrap_or_default() } } }   :1517
                                                ← upstream: let responseId: string | null = null   (openai-responses-language-model.ts:1587)
                                                   flush → providerMetadata.responseId: responseId → null   (:2932)
convert_responses_generate → { responseId: data.id or null }        responses_convert.rs:328   (already null)

What this PR changes

let mut pm = json!({ "responseId": self.response_id });   responses_convert.rs:1517   (None → null)

Tests (tests/openai_upstream_e2e_test.rs): a_stream_without_response_created_finishes_with_a_null_response_id streams only response.completed; on master it fails with left: String(""), right: Null. The upstream case is ported in the Azure test PR.

Docs: CHANGELOG Fixed.

Note: Nothing in the workspace reads responseId back from the finish metadata.

3. OpenAI Responses reasoning deltas carry the item id

Before: OpenAI and Azure Responses reasoning deltas had no provider metadata, while their reasoning start and end parts carried { <key>: { itemId, reasoningEncryptedContent } }.

After: as in @ai-sdk/openai 4.0.83, every reasoning delta carries { <key>: { itemId } }.

Found while porting the upstream Azure tests (case responses › doStream › reasoning › should stream with reasoning encrypted content include reasoning-delta part, whose snapshot has the item id on all 89 deltas).

How it works today

OpenAIResponsesLanguageModel::do_stream
└─ ResponsesStreamTransformer
   ├─ "response.reasoning_summary_part.added" → ReasoningStart { provider_metadata: reasoning_stream_metadata(..) }   responses_convert.rs:999
   ├─ "response.reasoning_summary_text.delta"
   │    └─ controller.reasoning_delta(id, delta)          → provider_metadata: None           responses_convert.rs:1059
   │                                                       ← upstream: providerMetadata: { [key]: { itemId } }
   │                                                          (openai-responses-language-model.ts:2735-2749)
   └─ "response.reasoning_summary_part.done" → ReasoningEnd { provider_metadata: .. }

What this PR changes

"response.reasoning_summary_text.delta"                                                  responses_convert.rs:1059
└─ controller.enqueue(StreamPart::ReasoningDelta {
       id, delta,
       provider_metadata: Some(provider_namespace(provider_key, { "itemId": item_id })),
   })

Tests (tests/openai_upstream_e2e_test.rs): reasoning_deltas_carry_the_item_id streams one reasoning summary delta; on master it fails with left: Null, right: {"openai":{"itemId":"rs_1"}}. The upstream case is ported in the Azure test PR.

Docs: CHANGELOG Fixed.

Note: Upstream resolves the item id through resolveOutputItemId(item_id, output_index); aimux's reasoning start and end parts use item_id directly, and this PR does the same for deltas.

Type of change

• Bug fix (non-breaking)
• New feature (non-breaking)
• Breaking change
• New provider
• New / updated binding
• Docs / RFC

Checklist

• cargo +1.99 fmt -p aimux-providers -- --check passes
• cargo +1.99 clippy -p aimux-providers --lib --tests -- -D warnings passes
• cargo +1.99 test -p aimux-providers: 129 test binaries, all pass
• scripts/check_provider_boundaries.sh passes
• Updated relevant docs (CHANGELOG)
• Commit messages follow Conventional Commits

Notes for reviewers

• Base is master. The commits are in the order above and can be reviewed one at a time.
• Closed in favour of this PR: fix: OpenAI file search sends max_num_results as an integer #321, fix: OpenAI Responses stream reports a null response id #322. Their branches stay as they are.
• Azure reuses this OpenAI code, which is why all three differences showed up in the Azure tests.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RoxcKU4zBD64Lri3e4Lrq5

[eric8810]

reasoning delta 现在带 item id，但用的是原始 item_id；上游在 output_item.added 按 output_index 记录并在三个 summary 分支用 resolveOutputItemId。Responses-compatible 旋转 opaque id 时，新的 providerMetadata/openai/itemId 与 reasoning-start 的 {id}:0 不一致，可能开出第二个 reasoning part。建议按 output_index 解析，并让测试使用 rotated id + output_index:0。另：FileSearchArgs.max_num_results 的 f64→u32 是公开类型破坏性变化，请移到 CHANGELOG 的 Breaking。

[cunninghamcard-bit]

eric 的意见（原话）	处理
「reasoning delta 现在带 item id，但用的是原始 item_id；上游在 output_item.added 按 output_index 记录并在三个 summary 分支用 resolveOutputItemId…建议按 output_index 解析」	b185778：新增 resolve_output_item_id，reasoning_summary_part.added、reasoning_summary_text.delta、reasoning_summary_part.done 三处都按 output_index 取 output_item.added 记下的 id；reasoning 的 output_item.done 结束时移除该记录，与上游一致
「并让测试使用 rotated id + output_index:0」	同一提交：reasoning_deltas_carry_the_item_id 的 summary 事件改用 rs_2 / rs_3 + output_index: 0，仍期望 itemId: rs_1；另加 rotated_reasoning_item_ids_are_correlated_by_output_index
「FileSearchArgs.max_num_results 的 f64→u32 是公开类型破坏性变化，请移到 CHANGELOG 的 Breaking」	5d4c318：条目移到 Breaking，并写明调用方现在要传整数

另：d6f40825 合入了最新 master（只有 CHANGELOG 冲突，两边都保留）。本地全量检查通过（fmt、边界脚本、clippy、2825 个测试）。

---

Generated by Claude Code

---

Generated by Claude Code

[eric8810]

inference 现在按 output_index 的 resolve_output_item_id 解析 rotated id，测试覆盖 rs_1..rs_5；FileSearchArgs 的 u32 变更已移入 Breaking。Approve。

[cunninghamcard-bit]

情况	处理
#368 先合入了 master（4d8ae891），它带着本 PR 的全部改动：提交 1-3（null responseId、reasoning delta 的 item id、file search 整数）、按 output_index 解析轮换 id（resolve_output_item_id）、对应的 4 个测试和 CHANGELOG 条目（max_num_results 在 Breaking）	核对过：tools.rs 的 max_num_results: Option<u32>、responses_convert.rs 的 resolve_output_item_id、file_search_sends_max_num_results_as_an_integer / a_stream_without_response_created_finishes_with_a_null_response_id / reasoning_deltas_carry_the_item_id / rotated_reasoning_item_ids_are_correlated_by_output_index 四个测试和四条 CHANGELOG 在 master 上都已存在。本 PR 合 master 后没有剩余改动，所以关闭
叠在本分支上的 Azure 测试 PR #324	改基到 master 并合入 master

---

Generated by Claude Code

---

Generated by Claude Code