Conversation
fix(client): mark some request bodies as optional
| headers = httpx.Headers(headers_dict) | ||
|
|
There was a problem hiding this comment.
Idempotency header now skipped when key is falsy
The old guard was options.method.lower() != "get" and idempotency_header not in headers, which ensured the header was always sent for non-GET requests (generating a key on the fly if none was provided). The new guard is options.idempotency_key and idempotency_header not in headers, which will silently skip the header if idempotency_key happens to be an empty string "" rather than None.
In practice this is safe because idempotency_key is populated earlier in request() via self._idempotency_key(), which generates a UUID and is never an empty string. However, a caller that explicitly sets options.idempotency_key = "" to suppress the header would get different behaviour between the old and new code (old: header sent with an auto-generated value; new: header not sent). This is a subtle semantic difference worth documenting.
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/brainbase/_base_client.py
Line: 441-442
Comment:
**Idempotency header now skipped when key is falsy**
The old guard was `options.method.lower() != "get" and idempotency_header not in headers`, which ensured the header was always sent for non-GET requests (generating a key on the fly if none was provided). The new guard is `options.idempotency_key and idempotency_header not in headers`, which will silently skip the header if `idempotency_key` happens to be an empty string `""` rather than `None`.
In practice this is safe because `idempotency_key` is populated earlier in `request()` via `self._idempotency_key()`, which generates a UUID and is never an empty string. However, a caller that explicitly sets `options.idempotency_key = ""` to suppress the header would get different behaviour between the old and new code (old: header sent with an auto-generated value; new: header not sent). This is a subtle semantic difference worth documenting.
How can I resolve this? If you propose a fix, please make it concise.|
|
||
| from .voice_deployment import VoiceDeployment as VoiceDeployment | ||
| from .voice_create_params import VoiceCreateParams as VoiceCreateParams | ||
| from .voice_list_response import VoiceListResponse as VoiceListResponse | ||
| from .voice_update_params import VoiceUpdateParams as VoiceUpdateParams |
There was a problem hiding this comment.
Breaking removal of VoiceCreateResponse, VoiceRetrieveResponse, VoiceUpdateResponse, and VoiceListResponseItem
All four names that were previously part of the public exports of this sub-package have been removed. Users who imported any of them directly will receive an ImportError after upgrading:
from brainbase.types.workers.deployments import VoiceCreateResponse # ImportError in 4.1.0
from brainbase.types.workers.deployments import VoiceRetrieveResponse # ImportError in 4.1.0
from brainbase.types.workers.deployments import VoiceUpdateResponse # ImportError in 4.1.0
from brainbase.types.workers.deployments import VoiceListResponseItem # ImportError in 4.1.0The new equivalent is VoiceDeployment. The CHANGELOG does not explicitly call out these individual name removals, so the migration path may not be obvious to users. Consider adding re-export aliases (e.g. VoiceCreateResponse = VoiceDeployment) with a deprecation warning, or at minimum documenting the renames in the CHANGELOG migration notes.
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/brainbase/types/workers/deployments/__init__.py
Line: 4-8
Comment:
**Breaking removal of `VoiceCreateResponse`, `VoiceRetrieveResponse`, `VoiceUpdateResponse`, and `VoiceListResponseItem`**
All four names that were previously part of the public exports of this sub-package have been removed. Users who imported any of them directly will receive an `ImportError` after upgrading:
```python
from brainbase.types.workers.deployments import VoiceCreateResponse # ImportError in 4.1.0
from brainbase.types.workers.deployments import VoiceRetrieveResponse # ImportError in 4.1.0
from brainbase.types.workers.deployments import VoiceUpdateResponse # ImportError in 4.1.0
from brainbase.types.workers.deployments import VoiceListResponseItem # ImportError in 4.1.0
```
The new equivalent is `VoiceDeployment`. The CHANGELOG does not explicitly call out these individual name removals, so the migration path may not be obvious to users. Consider adding re-export aliases (e.g. `VoiceCreateResponse = VoiceDeployment`) with a deprecation warning, or at minimum documenting the renames in the CHANGELOG migration notes.
How can I resolve this? If you propose a fix, please make it concise.|
🧪 Testing To try out this version of the SDK: Expires at: Mon, 06 Apr 2026 19:04:52 GMT |
dd993ea to
83c7404
Compare
Automated Release PR
4.1.0 (2026-03-07)
Full Changelog: v4.0.0...v4.1.0
Features
NotGivenfor body (#67) (3ad7f25)X-Stainless-Read-Timeoutheader (#63) (a594c75)Bug Fixes
model_dumpandmodel_dump_jsonfor Pydantic v1 (898ca7b)Chores
httpx-aiohttpversion to 0.1.9 (7aeb4c8)actions/github-script(bdad5ed)api.mdfiles (034e708)--fixargument to lint script (0b1e68e)test_proxy_environment_variablesmore resilient (f79d30c)test_proxy_environment_variablesmore resilient to env (08e33e4)pyproject.tomlfile (f87b268)actions/checkoutversion (54d6bd9)get_platformtest (ef07d85)Documentation
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