release: 0.67.0#275
Conversation
Pin all GitHub Actions referenced in generated workflows (both first-party `actions/*` and third-party) to immutable commit SHAs. Updating pinned actions is now a deliberate codegen-side bump rather than implicit on every workflow run.
|
🧪 Testing To try out this version of the SDK: Expires at: Fri, 12 Jun 2026 13:24:22 GMT |
stainless-app
Bot
force-pushed
the
release-please--branches--main--changes--next--components--sdk
branch
from
e83dd6d to
ace6611
Compare
stainless-app
Bot
force-pushed
the
release-please--branches--main--changes--next--components--sdk
branch
from
ace6611 to
262a7e0
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 262a7e0. Configure here.
| /** | ||
| * List of conditions or filters to be ANDed together | ||
| */ | ||
| all?: Array<unknown | Shared.SearchFilterCondition> | null; |
There was a problem hiding this comment.
unknown union makes SearchFilterCondition type constraint meaningless
Medium Severity
The all, any, and none fields in every SearchFilterInput interface use Array<unknown | Shared.SearchFilterCondition>. In TypeScript, unknown is the top type, so unknown | T always simplifies to just unknown. The Shared.SearchFilterCondition part of the union is completely absorbed and provides zero type-checking. This is a type safety regression from the prior SearchFilter type, which properly constrained array elements to SearchFilter | SearchFilterCondition. SDK users now get no type errors when passing arbitrary invalid values inside nested filter arrays.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 262a7e0. Configure here.
| * List of conditions or filters to be NOTed | ||
| */ | ||
| none?: Array<unknown | Shared.SearchFilterCondition> | null; | ||
| } |
There was a problem hiding this comment.
Duplicate SearchFilterInput interface declarations in each namespace
Low Severity
Every namespace (FileListParams, StoreMetadataFacetsParams, StoreQuestionAnsweringParams, StoreSearchParams) contains the SearchFilterInput interface declared twice with identical properties. TypeScript merges these via declaration merging, so no compilation error occurs, but the duplication is clearly unintentional from the code generator. Each namespace has an exact copy of the same interface immediately following itself.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 262a7e0. Configure here.
Automated Release PR
0.67.0 (2026-05-13)
Full Changelog: v0.66.0...v0.67.0
Features
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
Note
Medium Risk
Medium risk because it updates generated API surface/types (notably search filter typing) and includes duplicated
SearchFilterInputinterface declarations that could cause TypeScript compile/emit issues or confusing public types.Overview
Bumps the SDK to v0.67.0 (manifest,
package.json,src/version.ts, and changelog) and refreshes the OpenAPI spec pointer in.stats.yml.Updates generated Stores and Store Files request typings by removing the shared
SearchFiltertype and introducing per-endpointSearchFilterInputtypes forfilters/metadata_filter, with tests updated to use explicitSearchFilterConditionexamples and some parameter ordering tweaks.CI workflows now pin GitHub Actions (
checkout,setup-node,github-script) to specific commit SHAs for reproducibility.Reviewed by Cursor Bugbot for commit 262a7e0. Bugbot is set up for automated code reviews on this repo. Configure here.