Repository navigation
fix(openai): send type="message" on all Responses API message input items - #444
Merged
Merged
Conversation
…tems The Responses API marks `type` optional on message-shaped input items and OpenAI infers it, but some OpenAI-compatible servers (e.g. llama.cpp) only infer it for system/developer/user items and reject replayed assistant items without it, which is terminal for any tool-using conversation. Setting it explicitly is a no-op against OpenAI itself. VCR cassettes were hand-updated (bodies only; responses untouched) since body matching is structural JSON. Ports tidyverse/ellmer#1161 (fixes tidyverse/ellmer#1153).
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
1 participant
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.
Ports tidyverse/ellmer#1161 (fixes tidyverse/ellmer#1153).
Problem
Every message-shaped input item
ChatOpenAI()serializes for the Responses API (user/system text, images, PDFs, documents, uploaded-file references) carriedroleandcontentbut no top-leveltype.typeis optional in the published schema and OpenAI infers it, but llama.cpp's/v1/responsesparser only infers it forsystem/developer/useritems, notassistant— so a replayed assistant turn gets rejected withHTTP 400 Cannot determine type of 'item', which is terminal for any tool-using conversation.Fix
as_message()(the single helper all non-assistant message items go through) now includes"type": "message". The assistant-text path already set it. This is a no-op against OpenAI itself and fixes every OpenAI-compatible server that discriminates on it.Cassettes
Since VCR matches on (structurally parsed) request bodies, the 72 affected cassettes' recorded request bodies were hand-updated to add the new field — response bodies are untouched, so all recorded-response assertions (token counts, etc.) remain valid. This mirrors the approach taken in the ellmer PR.
Tests
test_all_message_input_items_carry_type_messagecovers text, PDF, and assistant items across roles.