Release Sandbox SDK 0.5.1 - #101
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: 6943d144fa
ℹ️ 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".
| image_data = self._connection.post( | ||
| path=f"{ApiPath.collection}/{self.id}/{ApiPath.generate}/{ApiPath.image}", | ||
| data={ | ||
| "prompt": prompt, | ||
| "aspect_ratio": aspect_ratio, | ||
| "callback_url": callback_url, | ||
| }, | ||
| data=payload, | ||
| ) |
There was a problem hiding this comment.
For the documented AsyncResponse returned by generation endpoints (openapi.yaml defines status: processing with data.output_url), this call uses HttpClient.post's default wait=True, so _parse_response consumes the async wrapper by polling output_url or returning None before this method can wrap it as a GenerationJob. In that response path, generate_image(..., wait=False) will still block/timeout or return None instead of the advertised async job; pass wait=False (at least for self-inference/job requests) so this code can handle the job payload itself.
Useful? React with 👍 / 👎.
| return Image(self._connection, **image_data) | ||
| if not image_data: | ||
| return None | ||
| if image_data.get("job_id"): |
There was a problem hiding this comment.
The shared async schema exposes the job identifier as data.id, and GenerationJob.from_data() already supports both job_id and id, but this guard only recognizes job_id. Once the async payload reaches this method (for example after bypassing response polling), a documented payload like {"id": "job-123", "output_url": ...} skips the job branch and tries to construct an Image from a job object, typically raising because collection_id is missing; the same job_id-only guard below affects OmniVoice audio jobs.
Useful? React with 👍 / 👎.
| :return: Details of the async response | ||
| :rtype: dict | ||
| """ | ||
| return self.get(path=f"{ApiPath.async_response}/{id}", wait=False) |
There was a problem hiding this comment.
When get_async_response() is used while an async operation is still processing (or has failed), wait=False takes the generic raw-response shortcut that returns only the top-level data field and drops the documented status/success wrapper from /async-response/{response_id}. Callers then cannot distinguish an incomplete or failed operation from a completed result, so this method should return the full wrapper rather than the unwrapped data.
Useful? React with 👍 / 👎.
| :param int interval: Seconds between polls (default 5) | ||
| :return: self | ||
| :raises RequestTimeoutError: If timeout is exceeded | ||
| """ |
There was a problem hiding this comment.
If a sandbox transitions to failed while wait_for_stop() is polling after stop(), this condition returns successfully because failed is included in TERMINAL_STATUSES. Since failed is distinct from stopped in the sandbox status enum, callers can proceed believing teardown completed normally even though the sandbox ended in an error state; return only on stopped and surface failed like wait_for_ready() does.
Useful? React with 👍 / 👎.
| """Poll an output URL until the job completes or times out.""" | ||
| start = time.monotonic() | ||
| while True: | ||
| response_json = self.session.get(url).json() |
There was a problem hiding this comment.
When a long-running sync request is being polled and a single output_url fetch hits a transient connection error, 5xx HTML page, or otherwise non-JSON response, this now escapes immediately from _get_output; the previous backoff.on_exception(..., max_time=500, interval=5) retried those exceptions while the job was in progress. This makes transcription/indexing/render calls fail on one flaky poll even though the job may still complete, so preserve retry handling around each poll fetch.
Useful? React with 👍 / 👎.
4 participants
No description provided.