[PR PREVIEW - DO NOT MERGE] 🌿 Fern Regeneration -- November 10, 2025 #844
Conversation
vellum-automation
bot
changed the title
![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.
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| * DEPRECATED: This endpoint is deprecated and will be removed in a future release. Please use the | ||
| * `retrieve_workflow_deployment_release` endpoint instead. | ||
| * | ||
| * @param {string} historyIdOrReleaseTag - Either the UUID of Workflow Deployment History Item you'd like to retrieve, or the name of a Release Tag that's pointing to the Workflow Deployment History Item you'd like to retrieve. | ||
| * @param {string} id - Either the Workflow Deployment's ID or its unique name | ||
| * @param {string} historyIdOrReleaseTag - Either the UUID of Workflow Deployment History Item you'd like to retrieve, or the name of a Release Tag that's pointing to the Workflow Deployment History Item you'd like to retrieve. | ||
| * @param {WorkflowDeployments.RequestOptions} requestOptions - Request-specific configuration. | ||
| * | ||
| * @example | ||
| * await client.workflowDeployments.workflowDeploymentHistoryItemRetrieve("history_id_or_release_tag", "id") | ||
| * await client.workflowDeployments.workflowDeploymentHistoryItemRetrieve("id", "history_id_or_release_tag") | ||
| */ | ||
| public workflowDeploymentHistoryItemRetrieve( | ||
| historyIdOrReleaseTag: string, | ||
| id: string, | ||
| historyIdOrReleaseTag: string, | ||
| requestOptions?: WorkflowDeployments.RequestOptions, | ||
| ): core.HttpResponsePromise<Vellum.WorkflowDeploymentHistoryItem> { | ||
| return core.HttpResponsePromise.fromPromise( | ||
| this.__workflowDeploymentHistoryItemRetrieve(historyIdOrReleaseTag, id, requestOptions), | ||
| this.__workflowDeploymentHistoryItemRetrieve(id, historyIdOrReleaseTag, requestOptions), | ||
| ); |
There was a problem hiding this comment.
Both workflowDeploymentEventExecution and workflowDeploymentHistoryItemRetrieve swapped their parameter order so that id now precedes executionId/historyIdOrReleaseTag. In 1.10.0 these methods accepted the subordinate identifier first, meaning existing callers will still compile after upgrading because both arguments are strings, but the values will be sent in the wrong URL slots (/v1/workflow-deployments/{executionId}/…/{id}), likely returning 404s. Because this is a patch release, the change is a silent breaking change for every existing user of these methods. Consider keeping the original order, adding an overload, or clearly deprecating the old signature before removing it.
Useful? React with 👍 / 👎.
| * DEPRECATED: This endpoint is deprecated and will be removed in a future release. Please use the | ||
| * `retrieve_prompt_deployment_release` xendpoint instead. | ||
| * | ||
| * @param {string} historyIdOrReleaseTag - Either the UUID of Deployment History Item you'd like to retrieve, or the name of a Release Tag that's pointing to the Deployment History Item you'd like to retrieve. | ||
| * @param {string} id - Either the Prompt Deployment's ID or its unique name | ||
| * @param {string} historyIdOrReleaseTag - Either the UUID of Deployment History Item you'd like to retrieve, or the name of a Release Tag that's pointing to the Deployment History Item you'd like to retrieve. | ||
| * @param {Deployments.RequestOptions} requestOptions - Request-specific configuration. | ||
| * | ||
| * @example | ||
| * await client.deployments.deploymentHistoryItemRetrieve("history_id_or_release_tag", "id") | ||
| * await client.deployments.deploymentHistoryItemRetrieve("id", "history_id_or_release_tag") | ||
| */ | ||
| public deploymentHistoryItemRetrieve( | ||
| historyIdOrReleaseTag: string, | ||
| id: string, | ||
| historyIdOrReleaseTag: string, | ||
| requestOptions?: Deployments.RequestOptions, | ||
| ): core.HttpResponsePromise<Vellum.DeploymentHistoryItem> { | ||
| return core.HttpResponsePromise.fromPromise( | ||
| this.__deploymentHistoryItemRetrieve(historyIdOrReleaseTag, id, requestOptions), | ||
| this.__deploymentHistoryItemRetrieve(id, historyIdOrReleaseTag, requestOptions), | ||
| ); | ||
| } | ||
|
|
||
| private async __deploymentHistoryItemRetrieve( | ||
| historyIdOrReleaseTag: string, | ||
| id: string, | ||
| historyIdOrReleaseTag: string, | ||
| requestOptions?: Deployments.RequestOptions, |
There was a problem hiding this comment.
The deploymentHistoryItemRetrieve helper now takes id before historyIdOrReleaseTag, whereas in 1.10.0 the history identifier came first. Because both parameters are plain strings, existing code will compile but will request /v1/deployments/{historyId}/history/{id} instead of the intended /…/{id}/history/{historyId}, breaking clients when they upgrade to 1.10.1. This is an unexpected behavioral change for a patch release; consider preserving the previous signature or providing a backwards‑compatible overload.
Useful? React with 👍 / 👎.
| * }) | ||
| */ | ||
| public executeIntegrationTool( | ||
| integrationName: string, | ||
| integrationProvider: string, | ||
| integrationName: string, | ||
| toolName: string, | ||
| request: Vellum.ComponentsSchemasComposioExecuteToolRequest, | ||
| requestOptions?: Integrations.RequestOptions, | ||
| ): core.HttpResponsePromise<Vellum.ComponentsSchemasComposioExecuteToolResponse> { | ||
| return core.HttpResponsePromise.fromPromise( | ||
| this.__executeIntegrationTool(integrationName, integrationProvider, toolName, request, requestOptions), | ||
| this.__executeIntegrationTool(integrationProvider, integrationName, toolName, request, requestOptions), | ||
| ); | ||
| } | ||
|
|
||
| private async __executeIntegrationTool( | ||
| integrationName: string, | ||
| integrationProvider: string, | ||
| integrationName: string, | ||
| toolName: string, |
There was a problem hiding this comment.
retrieveIntegrationToolDefinition and executeIntegrationTool now accept (integrationProvider, integrationName) instead of (integrationName, integrationProvider). Existing callers that were written against 1.10.0 will still type‑check, but the arguments will be inverted in the generated path (integrations/v1/providers/{integration_name}/integrations/{integration_provider}/…) leading to 404s or wrong tool execution after the upgrade. This breaking change in a patch version likely needs an overload or a deprecation path to avoid silently breaking users.
Useful? React with 👍 / 👎.
This PR regenerates code to match the latest API Definition.