fix(respect): keep step outputs on a same-workflow goto

[ariesclark]

What/Why/How?

Note

This was heavily assisted by Anthropic's Opus 5. I'm submitting it by hand, having done my due diligence on it. If I've missed something obvious, just say and I'll sort it out.

runWorkflow clears ctx.$steps on entry. A goto targeting a stepId re-enters runWorkflow with fromStepId, so outputs of steps that already ran are discarded:

- stepId: create-group
  operationId: $sourceDescriptions.api.createGroup
  outputs:
    groupId: $response.body#/id

- stepId: represent-group
  operationId: $sourceDescriptions.api.updateGroupRepresentation
  successCriteria:
    - condition: $statusCode == 200
  onFailure:
    - name: cleanup
      type: goto
      stepId: delete-group

- stepId: delete-group
  operationId: $sourceDescriptions.api.deleteGroup
  parameters:
    - name: groupId
      in: path
      value: $steps.create-group.outputs.groupId

When represent-group fails, the goto fires and delete-group errors:

Error in resolving runtime expression '$steps.create-group.outputs.groupId'.

The Arazzo specification describes a stepId goto as "a one-way transfer of workflow control" to a step "within the current workflow", and separately requires tools to treat runtime expression output references such as $steps.stepId.outputs.field as implicit dependencies and to ensure the referenced step completes before the referencing step executes.

Neither statement discards step context, so clearing it on re-entry was never spec behaviour. ctx.$steps is now cleared only when fromStepId is absent. A goto or retry that names a workflowId still goes through resolveWorkflowContext and still gets a clean $steps namespace.

Reference

No existing issue. #2735 and #2796 add action parameters, which the specification limits to actions referencing a workflowId, so they do not reach the stepId case.

https://github.com/OAI/Arazzo-Specification/blob/main/versions/1.1.0.md#failure-action-object

Testing

tests/e2e/respect/goto-step-keeps-outputs runs the CLI against an Arazzo document where a failing step routes onFailure: goto to a later step that reads an earlier step's output. It fails on main with the error above and passes with this change.

Screenshots (optional)

Check yourself

• This PR follows the contributing guide
• All new/updated code is covered by tests
• Core code changed? - Tested with other Redocly products (internal contributions only)
• New package installed? - Tested in different environments (browser/node)
• Documentation update has been considered

Security

• The security impact of the change has been considered
• Code follows company security practices and guidelines

---

Note

Medium Risk
Changes workflow execution context for goto/retry paths; behavior is narrower and spec-aligned but could affect workflows that accidentally relied on full $steps reset on re-entry.

Overview
respect no longer wipes all $steps when a goto (or step retry) resumes a workflow from a stepId. Previously runWorkflow always reset ctx.$steps on entry, so a same-workflow goto dropped outputs from steps that had already run and broke expressions like $steps.list-menu-items.outputs.menuItems.

On a fresh workflow run, $steps is still cleared entirely. On resume via fromStepId, outputs from steps before the jump are kept; only step IDs in the slice that will run again are removed from $steps. Goto/retry that targets another workflow still goes through resolveWorkflowContext and gets a clean step namespace as before.

An e2e Respect test covers onFailure: goto to a later step that reads an earlier step’s output.

^{Reviewed by Cursor Bugbot for commit f158d11. Bugbot is set up for automated code reviews on this repo. Configure here.}

[changeset-bot]

🦋 Changeset detected

Latest commit: f158d11

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 4 packages

Name	Type
@redocly/respect-core	Patch
@redocly/cli	Patch
@redocly/openapi-core	Patch
@redocly/client-generator	Patch

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

[github-actions]

Performance Benchmark (Lower is Faster)

CLI Version	Bundle	Lint	Check Config
cli-latest	▓ 1.03x ± 0.01	▓ 1.03x ± 0.01	▓▓▓▓▓ 1.14x ± 0.02
cli-next	▓ 1.00x (Fastest)	▓ 1.00x (Fastest)	▓ 1.00x (Fastest)

[Copilot]

🟡 Changes recommended

Resuming without clearing entries for steps at/after fromStepId can expose stale outputs (and stale $workflows step data) if a goto targets an earlier step.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Adjusts Respect’s workflow execution context handling so same-workflow goto stepId does not discard previously produced step outputs, aligning runtime $steps.<id>.outputs.* resolution with expected Arazzo semantics and adding an e2e regression test.

Changes:

• Update runWorkflow to avoid wiping ctx.$steps when resuming execution from a fromStepId (same-workflow goto path).
• Add a new Respect e2e fixture + snapshot validating that a cleanup step reached via onFailure: goto can read outputs from an earlier step.
• Add a patch changeset for @redocly/respect-core and @redocly/cli.

File summaries

File	Description
packages/respect-core/src/modules/flow-runner/runner.ts	Changes when $steps is cleared on workflow (re-)entry to preserve step outputs across same-workflow goto.
tests/e2e/respect/goto-step-keeps-outputs/goto-step-keeps-outputs.test.ts	Adds e2e test invoking respect against the new fixture.
tests/e2e/respect/goto-step-keeps-outputs/goto-step-keeps-outputs.arazzo.yaml	Adds an Arazzo workflow fixture that fails a step then gotos a cleanup step referencing earlier outputs.
tests/e2e/respect/goto-step-keeps-outputs/__snapshots__/goto-step-keeps-outputs.test.ts.snap	Snapshot asserting the expected CLI output for the new e2e scenario.
.changeset/tall-moons-repeat.md	Patch changeset documenting the fix.

Review details

• Files reviewed: 5/5 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.