fix: preserve tool_search output item IDs after provider metadata round trips - #17678
Conversation
Bugfix reviewOutcome: approved Reproduction replayStatus: no-longer-reproduces The exact original reproduction completed successfully and the original bug signal did not appear. Fixes issueStatus: fully-addresses The tool-search result branch now follows the required precedence of providerOptions, providerMetadata, then toolCallId, preserving the distinct output item ID. Side effectsRisk: low Existing providerOptions behavior and fallback behavior remain intact; only tool-search results carrying providerMetadata gain the previously omitted ID handling. PerformanceRisk: low The change adds one constant-time optional metadata lookup per relevant tool-search result and introduces no allocations or retained state of consequence. Backwards compatibilityRisk: low Stored data is not mutated, providerOptions retains precedence, and histories containing response-produced providerMetadata now serialize correctly rather than duplicating the call ID. ArchitectureRisk: low The fix is localized to the OpenAI Responses prompt converter, mirrors its existing tool-call compatibility logic, and adds no dependencies, exports, or cross-package abstractions. Change scopeStatus: minimal The diff contains only the targeted serializer change, a focused regression test preserving both metadata paths, and the required patch changeset. SecurityRisk: low The change only selects an existing provider item identifier and introduces no new parsing, network access, credential handling, or executable input path. TestingStatus: appropriate The regression test reproduces the realistic providerMetadata round trip and asserts distinct call and output references; existing providerOptions coverage remains in place. VerificationInspected the complete merge-base diff and adjacent parser/converter paths. The focused converter suites passed in both Node and Edge environments with 119 tests each, and workspace type checking plus lint and formatting checks passed. |
| @@ -0,0 +1,64 @@ | |||
| import type { ToolNameMapping } from '../../../provider-utils/src/create-tool-name-mapping'; | |||
There was a problem hiding this comment.
import needs to be @provider-utils/create-tool-name-mapping
There was a problem hiding this comment.
Updated the test to import ToolNameMapping from the resolvable @ai-sdk/provider-utils package entrypoint instead of reaching into provider-utils through a deep relative source path.
|
Addressed PR comment 5043162580.
No behavioral change was needed from the approval; the serializer precedence, regression coverage, and changeset remain intact. Verification was rerun after the subsequent import correction. |
Bugfix reviewOutcome: approved Reproduction replayStatus: no-longer-reproduces The exact original reproduction completed successfully and the original bug signal did not appear. Fixes issueStatus: fully-addresses The tool-search result serializer now reads itemId from providerOptions first, providerMetadata second, and toolCallId last, preserving distinct call and output references. Side effectsRisk: low Existing providerOptions precedence and toolCallId fallback remain unchanged; only histories carrying the previously ignored providerMetadata item ID serialize differently. PerformanceRisk: low The change adds one constant-time optional metadata lookup per hosted tool-search result and introduces no material allocations or retained state. Backwards compatibilityRisk: low No stored data is mutated or migrated; existing histories now use their preserved output item ID when serialized, while older histories without metadata retain the toolCallId fallback. ArchitectureRisk: low The behavior remains localized to the OpenAI Responses converter, mirrors the adjacent tool-call compatibility logic, and adds no dependencies, exports, or cross-package abstractions. Change scopeStatus: minimal The diff contains only the targeted converter change, focused regression coverage retaining both metadata paths, and the required patch changeset. SecurityRisk: low The change only selects an existing provider item identifier and adds no parsing, network, credential, URL-handling, or executable-input behavior. TestingStatus: appropriate The regression test covers the realistic providerMetadata round trip and distinct stored references, while existing tests continue covering providerOptions behavior and fallback-related converter behavior. VerificationInspected the complete merge-base diff and adjacent OpenAI response parser and converter paths. The OpenAI Node and Edge suites each passed 791 tests, package type checking passed, and focused lint, formatting, and diff checks reported no issues. |
…ata round trips (#17690) ## Background Stored OpenAI Responses continuations could duplicate a hosted tool_search call item ID, causing OpenAI to reject the request. ## Root Cause The response parser stores the tool-search output item ID in providerMetadata, but the result serializer previously read only providerOptions and therefore fell back to toolCallId. The reproduction showed this emitted the call ID twice instead of preserving distinct call and output IDs. ## Summary Updated tool-search result serialization to prefer providerOptions, then providerMetadata, then toolCallId; added focused regression coverage using the package-level provider-utils type import; and added a patch changeset. ## Testing Regression coverage asserts distinct stored call and output references after a providerMetadata round trip. The OpenAI Node and Edge suites each passed 791 tests, and workspace type checking plus lint and formatting checks passed. ## End-to-end Validation - `pnpm -C examples/ai-functions exec tsx src/generate-text/openai/responses-tool-search.ts` — live OpenAI run completed successfully with distinct `tsc_...` and `tso_...` IDs and no duplicate-item rejection. ## Related Issues Fixes #17666 Closes #17674 Backport of #17678 Co-authored-by: seandearnaley <5084762+seandearnaley@users.noreply.github.com> Co-authored-by: lgrammel <205036+lgrammel@users.noreply.github.com>
|
🚀 Published in:
|
1 participant
Background
Stored OpenAI Responses continuations could duplicate a hosted tool_search call item ID, causing OpenAI to reject the request.
Root Cause
The response parser stores the tool-search output item ID in providerMetadata, but the result serializer previously read only providerOptions and therefore fell back to toolCallId. The reproduction showed this emitted the call ID twice instead of preserving distinct call and output IDs.
Summary
Updated tool-search result serialization to prefer providerOptions, then providerMetadata, then toolCallId; added focused regression coverage using the package-level provider-utils type import; and added a patch changeset.
Testing
Regression coverage asserts distinct stored call and output references after a providerMetadata round trip. The OpenAI Node and Edge suites each passed 791 tests, and workspace type checking plus lint and formatting checks passed.
End-to-end Validation
pnpm -C examples/ai-functions exec tsx src/generate-text/openai/responses-tool-search.ts— live OpenAI run completed successfully with distincttsc_...andtso_...IDs and no duplicate-item rejection.Related Issues
Fixes #17666
Closes #17674
Co-authored-by: seandearnaley 5084762+seandearnaley@users.noreply.github.com
Co-authored-by: lgrammel 205036+lgrammel@users.noreply.github.com