[codex] Expose sync timeout as queryable error#1
Conversation
|
Claude encountered an error —— View job I'll analyze this and get back to you. |
![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: 8a68edd142
ℹ️ 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".
| request. If the server-side sync wait times out, the SDK returns an error with | ||
| the task ID/result URL; the task continues processing and can be queried later. |
There was a problem hiding this comment.
With default client settings, this documented path only works if the server returns before 10 seconds: submit still sets http.Client.Timeout from c.connectionTimeout (10s default), so a server-side sync wait that times out after the API's longer wait window is cut off locally before the JSON body containing the task ID/URLs can be decoded. In that sync-timeout case callers get a generic client timeout (and task retries may resubmit) instead of the queryable task error promised here; the sync POST needs a read/request timeout based on the run timeout, or this doc must require increasing the connection timeout.
Useful? React with 👍 / 👎.
| return syncResultCode(data) == 5004 || | ||
| (status == "processing" && strings.Contains(errorMsg, "Sync mode timed out")) |
There was a problem hiding this comment.
When a sync response is already terminal with status: "failed" and code: 5004 (a task timeout/failure), this predicate treats the code alone as a still-processing sync-mode timeout. That makes Run() tell callers to query later and makes RunNoThrow() report Detail.Status == "processing", even though the task has failed; gate code 5004 on a non-terminal/processing status or the sync-timeout message instead of ignoring status.
Useful? React with 👍 / 👎.
1 participant
What changed
code,created_at, andurlsfrom sync-mode responses.Run()return shape unchanged.processingstatus plusTaskID/ResultURLfromRunNoThrow()for sync timeout.Why
A sync timeout means the prediction is still processing asynchronously. Go callers need to distinguish that from prediction failure and query the task later.
User impact
Run(..., WithSyncMode(true))returns a non-nil error on sync timeout with the task ID/result URL.RunNoThrow()exposes the query data structurally inDetail.Validation
go test ./...git diff --check