-
Notifications
You must be signed in to change notification settings - Fork 47
release: 0.3.0 #42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
release: 0.3.0 #42
Conversation
|
🧪 Testing To try out this version of the SDK, run: Expires at: Thu, 12 Mar 2026 07:53:11 GMT |
ac5c5d9 to
c72a9be
Compare
c72a9be to
00246c5
Compare
| *, | ||
| cast_to: Type[ResponseT], | ||
| body: Body | None = None, | ||
| content: BinaryTypes | None = None, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Iterator content silently lost on request retry
Medium Severity
When content is an Iterable[bytes] (like a generator), the iterator is consumed on the first request attempt. If a retryable error occurs, the retry logic uses model_copy which performs a shallow copy, so options.content still references the same exhausted iterator. Subsequent retry attempts send an empty request body. This is exacerbated by DEFAULT_MAX_RETRIES being increased from 0 to 2 in this same PR. Users passing generator-based content could experience silent data loss on transient failures.
Additional Locations (1)
00246c5 to
f4bfcf4
Compare
f4bfcf4 to
120f4f7
Compare
120f4f7 to
b02a9df
Compare
PR SummaryMedium Risk Overview On the SDK side, this adds new API surfaces for OCR ( The HTTP client is updated to (1) support sending raw/binary request bodies via a new Written by Cursor Bugbot for commit 1ca826f. This will update automatically on new commits. Configure here. |
b02a9df to
3c98764
Compare
| [], | ||
| steps, | ||
| verbose=exec_config.verbose, | ||
| ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing assistant message before tool execution in streaming paths
High Severity
Both streaming paths (_execute_streaming_async and _execute_streaming_sync) call the scheduler's execute_local_tools_async/execute_local_tools_sync without first appending an assistant message with tool_calls to the messages list. The scheduler's own docstring explicitly states the caller is responsible for this. The non-streaming paths (_execute_tool_calls at line 1204, _execute_tool_calls_sync at line 1229) correctly append {"role": "assistant", "tool_calls": ...} before calling the scheduler. The old streaming code also did this but the line was removed during the refactoring. This produces a malformed conversation (tool messages without a preceding assistant message), which will cause the API to reject subsequent requests.
Additional Locations (1)
| # Collect MCP tool results emitted by the server | ||
| chunk_extra = getattr(chunk, "__pydantic_extra__", None) or {} | ||
| if isinstance(chunk_extra, dict) and "mcp_tool_results" in chunk_extra: | ||
| mcp_tool_results_from_server = chunk_extra["mcp_tool_results"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Collected MCP tool results variable is never used
Low Severity
mcp_tool_results_from_server is assigned in both _execute_streaming_async and _execute_streaming_sync but is never read after assignment. The variable is dead code — the collected MCP tool results are silently discarded. Given the PR includes a fix for "inject server tool results into conversation for mixed tool calls," this may represent an incomplete implementation for the streaming paths.
Additional Locations (1)
This comment has been minimized.
This comment has been minimized.
3c98764 to
b8e048e
Compare
b8e048e to
a3df0b4
Compare
a3df0b4 to
d04fc33
Compare
d04fc33 to
2fef7e6
Compare
2fef7e6 to
1ca826f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is ON. A Cloud Agent has been kicked off to fix the reported issue.
| content_chunks = 0 | ||
| tool_call_chunks = 0 | ||
| finish_reason = None | ||
| mcp_tool_results_from_server: list = [] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unbound response variable when loop body never executes
Medium Severity
The newly added _extract_mcp_results(response) after the while loop in both _execute_turns_async and _execute_turns_sync references response, which is only assigned inside the loop body. If max_steps is zero or negative (allowed by the run() API and by _apply_policy override), the loop never executes, response is never bound, and this line raises an UnboundLocalError. The old code's return statement did not reference response, so this is a new crash path.
Additional Locations (1)
|
Bugbot Autofix prepared fixes for 1 of the 1 bugs found in the latest run.
Or push these changes by commenting: Preview (28c2d03413)diff --git a/src/dedalus_labs/lib/runner/core.py b/src/dedalus_labs/lib/runner/core.py
--- a/src/dedalus_labs/lib/runner/core.py
+++ b/src/dedalus_labs/lib/runner/core.py
@@ -508,6 +508,7 @@
final_text = ""
tool_results: list[ToolResult] = []
tools_called: list[str] = []
+ response = None
while steps < exec_config.max_steps:
steps += 1
@@ -809,6 +810,7 @@
final_text = ""
tool_results: list[ToolResult] = []
tools_called: list[str] = []
+ response = None
while steps < exec_config.max_steps:
steps += 1 |



Automated Release PR
0.3.0 (2026-02-10)
Full Changelog: v0.2.0...v0.3.0
Features
Bug Fixes
Chores
actions/github-script(cf53a9e)actions/checkoutversion (c72dfca)This pull request is managed by Stainless's GitHub App.
The semver version number is based on included commit messages. Alternatively, you can manually set the version number in the title of this pull request.
For a better experience, it is recommended to use either rebase-merge or squash-merge when merging this pull request.
🔗 Stainless website
📚 Read the docs
🙋 Reach out for help or questions