fix: allow assistant messages in Responses input types - #3722
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ac126e924f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| role: Required[Literal["user", "system", "developer"]] | ||
| """The role of the message input. One of `user`, `system`, or `developer`.""" | ||
| role: Required[Literal["user", "assistant", "system", "developer"]] |
There was a problem hiding this comment.
This updates only the standalone ResponseInputItemParam duplicate. Responses.create accepts the separately generated ResponseInputParam, whose Message.role still excludes assistant; consequently, a valid assistant message carrying the optional status field cannot match either that Message or EasyInputMessageParam and is rejected by type checkers. The beta schema was also changed, but both beta request aliases retain the old role literal. Regenerate or update these duplicate request types so every endpoint represented by the changed schemas accepts the same messages.
Useful? React with 👍 / 👎.
| The role of the message input. One of `user`, `assistant`, `system`, or `developer`. | ||
| enum: | ||
| - user | ||
| - assistant |
There was a problem hiding this comment.
When an assistant input is returned by responses.input_items.list, the changed InputMessageResource schema permits it, but ResponseInputMessageItem.role still excludes assistant; the alternative ResponseOutputMessage cannot parse its input_text content, so SDK response validation fails instead of returning the item. The beta response model has the same mismatch. Regenerate the response-side models as well as the request aliases so returned assistant inputs deserialize correctly.
AGENTS.md reference: AGENTS.md:L5-L8
Useful? React with 👍 / 👎.
| The role of the message input. One of `user`, `assistant`, `system`, or `developer`. | ||
| enum: | ||
| - user | ||
| - assistant |
There was a problem hiding this comment.
Editing this generated specification changes its MD5 to ff0cd3df4caef970f68fce6b3a861161, while .castiron.stats.yml still records e37bbe0f04caa6093f1cb5d65d23ad03. As a result, scripts/mock exits with “Local OpenAPI specification does not match generation metadata,” and every normal ./scripts/test run that needs to start the local mock server stops before running tests. Regenerate the artifacts through the supported workflow rather than manually rewriting the generation metadata.
AGENTS.md reference: AGENTS.md:L16-L18
Useful? React with 👍 / 👎.
1 participant
Closes #3544
The Responses API accepts client-authored assistant turns without an id or status, but the generated
ResponseInputItemParamtype rejected the assistant role. This updates the generated type and OpenAPI schema enum so valid assistant input messages are accepted.Validation:
python3 -m compileall -q src