fix: pass workflow inputs to success and failure actions#2796
fix: pass workflow inputs to success and failure actions#2796harshit078 wants to merge 34 commits into
Conversation
🦋 Changeset detectedLatest commit: ae9e4c7 The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Thanks @harshit078 for contribution! Please, fix the issue reported by bugbot. I left comment as well. Additionally, please add docs for a new rule. |
|
Hey @AlbinaBlazhko17 , I have pushed a fix addressing both cursor and your comment along with addition of docs for |
|
|
||
| export const SpecParametersInByContext: Arazzo1Rule = () => { | ||
| return { | ||
| Step: { |
There was a problem hiding this comment.
Please, add to this rule Workflowvisitor, because you miss, that Workflow also accepts parameters per arazzo.ts:179.
|
Hey @AlbinaBlazhko17 , I have addressed the comments you left and created a seperate parameter interface and used that. I am not sure on how to resolve the 2 failing test though. Thanks ! |
| type: 'array', | ||
| items: parameter, | ||
| } as const; | ||
| export const actionParameter = { |
There was a problem hiding this comment.
Add please spacing between Parameters, actionParameter and actionParameters.
|
Hi @harshit078! Almost done, left minor comments, otherwise looks good.
|
|
Hi @AlbinaBlazhko17 , I have tried doing both the commands and pushed the commit for it but the tests still fails. Is there something I might be doing wrong ? |
|
Hi @harshit078! You fixed first batch of errors. Let's fix the second:
|
|
Hey @AlbinaBlazhko17 , thank you for helping me out. The PR is good to go on the check side. |
|
|
||
| ## Design principles | ||
|
|
||
| The Arazzo specification states that when a step, success action, or failure action specifies a `workflowId`, all parameters map to the referenced workflow's inputs and the `in` field MUST NOT be specified. |
There was a problem hiding this comment.
@harshit078
Please correct me if I’m wrong, but this statement seems to be inaccurate.
The Arazzo specification only mentions this for Success Action Object and Failure Action Object but not for the step.
A list of parameters that MUST be passed to a workflow as referenced by workflowId. If a Reusable Object is provided, it MUST link to a parameter defined in the [components/parameters](https://spec.openapis.org/arazzo/latest.html#components-object) of the current Arazzo document. The list MUST NOT include duplicate parameters. The `in` field MUST NOT be used.
There was a problem hiding this comment.
There was a problem hiding this comment.
I’d also like to clarify whether step-level parameters that don’t include an in field should be merged into the success and failure action objects.
Here is my question for the community => https://open-api.slack.com/archives/C022K8VD7AP/p1780496931264819
There was a problem hiding this comment.
I think I got confused on my end a bit but I agree, I assumed that step was included along with success and failure. I read the docs but couldnt open the slack archive as account was not there in that community and I have made changes to only keep to success and failure and revamped my verbiage in arrazo rules and also spec-parmaters context.ts
There was a problem hiding this comment.
Here is my question to the community, in case you were not able to join =>
Hi All,
I have a question regarding the recent parameter updates in Arazzo 1.1.
Could you please clarify this behavior for me?
Should step level parameters without in be merged into Success/Failure Action Objects?
workflows:
- workflowId: someWorkflow
steps:
- stepId: someStep
operationId: create
parameters:
- name: sort
in: query
value: '-name'
- name: endDate
value: '2026-08-08'
onSuccess:
- name: successFlow
workflowId: successActionWorkflowId
type: goto
parameters:
- name: startDate
value: '2026-01-01'
Will the successActionWorkflowId workflow have two input parameters (startDate and endDate), or only one (startDate) ?
Thank you.
I will add more details here after the reply.
| operationId: createTicket | ||
| onSuccess: | ||
| - name: end-with-params | ||
| type: end |
There was a problem hiding this comment.
It seems like parameters also won't make sense when action type is end.
What do you think?
There was a problem hiding this comment.
yes I agree, I'll remove it. it is redundant to have it.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit e1820da. Configure here.
| ...basicCTX, | ||
| $workflows: { | ||
| 'get-bird-workflow': { steps: {}, inputs: {} }, | ||
| 'success-action-workflow': { steps: {}, inputs: {} }, |
There was a problem hiding this comment.
I will clarify this with the Arazzo community, but in my opinion, only inputs defined by the workflow JSON Schema should be passed to the workflow.
In practice, this would mean that when parameters without in are passed to a workflow, only those defined in workflow.inputs JSON schema would be available in the workflow runtime context through $inputs.
Currently all of inputs are passed, and this was the behavior before changes in this PR.
There was a problem hiding this comment.
Ok, lets wait till then !

What/Why/How?
spec-parameters-in-by-contextArazzo ruleparametersproperty in interface of workflow for success and failure action objects.Reference
#2735
Testing
Screenshots (optional)
Check yourself
Security
Note
Medium Risk
Respect workflow branching now merges action parameters into target workflow inputs, which can change runtime behavior for existing Arazzo files; the new lint rule may surface warnings/errors on previously accepted documents.
Overview
Adds Arazzo support for
parameterson success and failure actions (name/value only, mapped to a referenced workflow’s inputs) and wires Respect so those values are merged into the target workflow’s$inputswhen agotoaction runs with aworkflowId.Introduces the
spec-parameters-in-by-contextlint rule: inline parameters must includeinon workflows and on steps that target operations (notworkflowId); actionparametersare only allowed when the action has aworkflowId. Schema/types gainActionParameter/ActionParameters;parameters-uniquealso applies to action parameter lists. Documentation, default rulesets, and tests cover the new rule and runtime behavior.Reviewed by Cursor Bugbot for commit ae9e4c7. Bugbot is set up for automated code reviews on this repo. Configure here.