Repository navigation
BatchRequestOutput object's error discrepancies #302
Description
It appears that the BatchRequestOutput object's error is missing properties and in an error response, that the actual error contents are nested under the body property.
The spec shows that a BatchRequestOutput object will contain id, custom_id, response, and error, and that the error property will have code and message:
However, when I construct a request that's intentionally designed to trigger a non-HTTP error (set max_tokens to 1000000 for a gpt-4o prompt), create/upload a file containing this request via the files endpoint, trigger a batch request with this file, and then retrieve the contents of the resulting Error file to inspect its contents, I see the following discrepancies:
- the
errorproperty is nulled, and theresponse.bodycontains the actual error contents - the
errorobject not only has thecodeandmessageproperties, but also hastypeandparamproperties
request:
{
"custom_id": "request-5",
"method": "POST",
"url": "/v1/chat/completions",
"body": {
"model": "gpt-4o",
"messages": [
{
"role": "system",
"content": "You are a helpful assistant."
},
{
"role": "user",
"content": "What is the capital of Texas?"
}
],
"max_tokens": 1000000
}
}
response:
"id": "batch_req_YTpodqz4ZJ8arId5Bm73lIEt",
"custom_id": "request-5",
"response": {
"status_code": 400,
"request_id": "0538a1cc8f8f8500bbe07250e6aa2b26",
"body": {
"error": {
"message": "This model's maximum context length is 128000 tokens. However, you requested 1000024 tokens (24 in the messages, 1000000 in the completion). Please reduce the length of the messages or completion.",
"type": "invalid_request_error",
"param": "messages",
"code": "context_length_exceeded"
}
}
},
"error": null
}
It appears that the spec should at least add the type and param properties to error, and that error should be 'moved'?
Activity
jtrajkovski commentedon Aug 2, 2024
PR to add the properties to the
BatchRequestOutputerror object can be found here: #303Not sure where to nest the
errorobject itself though. i.e. should it:bodyprop of theresponse(to reflect what's actually being returned)jbeckwith-oai commentedon Jul 17, 2026
Thank you for the careful reproduction, especially for including an intentionally failing Batch request and the exact JSONL result. Thank you also for following up with #303 to propose the missing
typeandparamfields.I reviewed both this issue and the proposed PR against the current specification. The important distinction is that the underlying service behavior has not been verified as changed; instead, the public OpenAPI contract has changed shape:
BatchRequestOutputis no longer present anywhere in the current specification.Batchschema exposesoutput_file_idfor successful request outputs anderror_file_idfor failed request outputs.BatchRequestOutput.errorproperty to extend or move.That makes the original schema discrepancy obsolete rather than evidence that the runtime nesting was corrected. I’m closing this because the requested change no longer has a target in the current public contract.
Your example remains useful context if typed Batch JSONL result records are introduced again. If the current specification should explicitly model those records, a fresh issue framed as “add schemas for Batch output/error JSONL lines,” with this payload as evidence, would be the clearest current request. Thanks again for the unusually concrete report and for contributing a proposed fix.