feature request: Support RedriveExecution for failed Standard Step Functions executions #63
AndreKurait
started this conversation in
Feature Requests (AWS)
Replies: 1 comment
|
Hi @AndreKurait, thanks for raising this. I have filed this in our internal tracker, so when this gets picked up we will make sure to notify you. I don't have an immediate ETA to share at the moment, but rest assured we will implement support for Thanks again for the request! |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Additional version check — 2026-10-08
Still unsupported: the eligible failed Standard execution's redrive returns HTTP 501; its original execution remains failed.
The comparison used an unmodified
localstack/localstack-pro:2026.8.1Linux ARM64 image,repository digest
sha256:4aef81c531684570d7b3cfd2805afa02194c929d52bbeedabb7d4874798b1572.Vendor packages were
localstack-core 2026.8.1,moto-ext 5.1.48, and bundledboto3/botocore 1.43.78. HTTP probes used a separateboto3/botocore 1.43.101client; the process-local security-group probe used the bundled interpreter.
The same scripts were used, with no custom extensions or provider source changes.
Owned test containers and the disposable network were removed.
This is a second specifically tested version, not a claim to have tested the latest release.
Existing report search
I searched the LocalStack issue tracker and current organization Discussions for this operation and failure. I did not find an existing report for this exact reproduction.
Current behavior
RedriveExecutionreturns HTTP 501InternalFailure, with a message stating that the operation is not implemented.The public API reproducer creates a Standard workflow containing a single
Failstate, runs it to its intentional failure, and immediately requests redrive. The execution is only seconds old and has three history events, so execution age and history-size limits do not explain the refusal. The rejected request leaves the original executionFAILED.This was reproduced on a fresh, unmodified LocalStack container. I am filing it as a missing capability, rather than treating an intentional
Failstate as an execution-engine bug.Expected behavior
Accept redrive for this eligible execution, return
redriveDate, preserve the original execution ARN/input/history, and append anExecutionRedrivenevent. Reentering the sameFailstate should fail again; that second failure is the correct outcome.References: RedriveExecution API and redrive behavior by state.
Starting a new execution from the beginning is not equivalent: it changes the execution identity and repeats completed work. Eligibility checks, client-token idempotence, and history preservation are part of the requested behavior.
Environment
localstack/localstack-pro:2026.7.5.sha256:0d74e1d2d7ce13a3cb25fc64cf15eb225f1c95c762e56e057bc6a9ed0ed29306.localstack-core 2026.7.5,moto-ext 5.1.46,moto.__version__ = 5.1.21.dev,boto3/botocore 1.43.51.Fresh confirmation on 2026-10-08: the same discrepancy reproduced on Linux ARM64 against the same unmodified image, using a separate
boto3/botocore 1.43.101client. The disposable container and network were removed after the run. The startup block below includes the run's disabled DNS listener/default EC2-image downloads and temporary state storage; no provider source or extension was changed.Steps to reproduce
Start a disposable instance on a free loopback port:
Run the block in a disposable shell. Port 4567 must be free. The client needs
boto3; it uses only dummy credentials and a loopback endpoint. It creates disposable resources and cleans them up infinally; the shell trap removes the container even when the script reports failure. A nonzero exit is expected while the reported discrepancy is present. No Docker socket mount or application services are required.Complete standalone reproducer: stepfunctions_redrive_execution.py
All reactions