Repository navigation
fix(ai): drop invalid item ids when replaying responses history - #44587
Merged
Merged
Conversation
Replaying history resends persisted item ids verbatim. A malformed, oversized, or foreign id can fail request validation server-side even when call_id pairing is intact. The Open Responses baseline now validates item id shape ([A-Za-z0-9_-], max 64 chars) and drops anything else at every lowering site: function call items, reasoning items (which are skipped entirely when the id is unusable), assistant message groups, and hosted tool item_reference synthesis. A new optional Extension.acceptsItemID hook lets provider routes enforce their own id grammar; the OpenAI route uses it to only resend msg_/rs_/fc_ prefixed ids per item kind while hosted tool references keep shape-only validation.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
When replaying conversation history to a Responses API, persisted item ids (
msg_,rs_,fc_, hosted tool ids) were resent verbatim from provider metadata. A malformed, oversized, or foreign id can fail request validation server-side even whencall_idpairing is intact — for example after switching models mid-session or when synthetic ids end up in history.Changes
open-responses.ts):itemID()now only accepts ids matching/^[A-Za-z0-9_-]{1,64}$/. Dropped ids are treated exactly like absent ones at every lowering site:function_callitems are resent without anidid(grouping splits so distinct original items stay distinct)item_referencesynthesisExtension.acceptsItemID(kind, id)lets provider routes enforce their own id grammar. The OpenAI route uses it to resend onlymsg_/rs_/fc_-prefixed ids for messages/reasoning/function calls; hosted tool references keep shape-only validation since every hosted tool mints its own prefix.This mirrors the allowlist approach codex uses before resending history (codex-rs
core/src/client.rs,prepare_response_items_for_requeststrips ids without a recognized prefix).Tests
fc_-prefixed item idsFull
packages/aisuite passes; the six OpenRouter failures are pre-existing onv2.