Repository navigation
fix: respect default retry limit - #3283
DmitryAnansky wants to merge 4 commits into
Conversation
🦋 Changeset detectedLatest commit: 5f903dc The changes in this PR will be included in the next version bump. This PR includes changesets to release 6 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 |
📝 Recheck Summaryℹ️ No Markdown files changed under |
Performance Benchmark (Lower is Faster)
|
Coverage Report
File Coverage
|
||||||||||||||||||||||||||||||||||||||||||||||||||
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 2 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 008efc9. Configure here.
kanoru3101
left a comment
There was a problem hiding this comment.
Overall, it looks good. Left a few minor improvements
c58d499 to
84f98ba
Compare

What/Why/How?
Fixed an issue where
respectdidn't retry a step when itsretryfailure action had noretryLimit.As the Arazzo specification defines, such an action now retries the step once, after running the workflow or step that the action references.
When a step runs out of retries,
respectnow runs the next matching failure action, or ends the workflow if there is none.A
retryaction that references astepIdalso no longer retries without limit when that step has its ownretryaction.Note: Previously, a workflow continued with the next step after a step had failed and used up its retries.
Now the workflow ends at that step unless a later failure action, such as
goto, says otherwise.Reference
Testing
Screenshots (optional)
Check yourself
Security
Note
Medium Risk
Changes workflow control flow after failed steps (retries, goto, workflow termination), which can alter existing Respect/Arazzo runs that relied on the old post-retry behavior.
Overview
Fixes Respect
onFailureretryhandling so it matches Arazzo whenretryLimitis omitted: the default is now 1 retry (was 0, so the step was never retried).When retries are exhausted, the runner
continues through the failure-action list instead of stopping early withshouldEnd: false, so the next matching action (e.g.goto) can run. Exhausted retries no longer implicitly advance to the next workflow step—the workflow ends at that step unless a later failure action says otherwise.For
retryactions that reference astepId, the nestedrunStepnow receivesretriesLeft - 1, preventing a target step’s own retry action from starting a fresh retry budget.Adds an e2e Respect fixture and snapshot coverage for retry-without-limit plus retry-then-goto and nested-step retry behavior; ships patch notes for
@redocly/cliand@redocly/respect-core.Reviewed by Cursor Bugbot for commit 008efc9. Configure here.