A TypeScript implementation of the Amazon States Language specification.
This package lets you run AWS Step Functions state machines completely locally, both in Node.js and in the browser!
To see the list of features defined in the specification that have full support, partial support, or no support, refer to this document.
Why would you want to use this package? Below is a non-exhaustive list of use cases for aws-local-stepfunctions
:
- Testing state machines changes locally before deploying them to AWS.
- Testing the integration between a state machine and the Lambda functions associated with it in
Task
states. - Debugging the code of associated Lambda functions interactively using the
Task
state resource override feature. - Debugging a state machine by using the event logs feature, to better understand the transitions between states and how data flows between them.
- Running state machines in the browser (not possible with AWS Step Functions Local).
npm install aws-local-stepfunctions
const { StateMachine } = require('aws-local-stepfunctions');
import { StateMachine } from 'aws-local-stepfunctions';
You can import the bundled package directly into a browser script as an ES module, from one of the following CDNs:
NOTE: The following examples will import the latest package version. Refer to the CDNs websites to know about other ways in which you can specify the package URL (for example, to import a specific version or a minified version).
import { StateMachine } from 'https://unpkg.com/aws-local-stepfunctions';
import { StateMachine } from 'https://cdn.jsdelivr.net/npm/aws-local-stepfunctions/build/main.browser.esm.js';
The constructor takes the following parameters:
definition
: The Amazon States Language definition of the state machine.stateMachineOptions?
:validationOptions?
: An object that specifies how the definition should be validated.checkPaths
: If set tofalse
, won't validate JSONPaths.checkArn
: If set tofalse
, won't validate ARN syntax inTask
states.noValidate
: If set totrue
, will skip validation of the definition entirely.NOTE: Use this option at your own risk, there are no guarantees when passing an invalid or non-standard definition to the state machine. Running it might result in undefined/unsupported behavior.
awsConfig?
: An object that specifies the AWS region and credentials to use when invoking a Lambda function in aTask
state. If not set, the AWS config will be resolved based on the credentials provider chain of the AWS SDK for JavaScript V3. You don't need to use this option if you have a shared config/credentials file (for example, if you have the AWS CLI installed) or if you use a local override for all of yourTask
states.region
: The AWS region where the Lambda functions are created.credentials
: An object that specifies which type of credentials to use.cognitoIdentityPool
: An object that specifies the Cognito Identity Pool ID to use for requesting credentials.accessKeys
: An object that specifies the Access Key ID and Secret Access Key to use as credentials.
The constructor will attempt to validate the definition by default, unless the validationOptions
property is specified. If the definition is not valid, an error will be thrown.
import { StateMachine } from 'aws-local-stepfunctions';
const machineDefinition = {
Comment: 'A simple minimal example of the States language',
StartAt: 'Hello World',
States: {
'Hello World': {
Type: 'Task',
Resource: 'arn:aws:lambda:us-east-1:123456789012:function:HelloWorld',
End: true,
},
},
};
// Instantiate a new state machine with the given definition and don't validate JSONPaths.
const stateMachine = new StateMachine(machineDefinition, {
validationOptions: { checkPaths: false },
});
Runs the state machine with the given input
.
Each execution is independent of all others, meaning that you can concurrently call this method as many times as needed, without worrying about race conditions.
input
: The initial input to pass to the state machine. This can be any valid JSON value.options?
:overrides?
: An object to override the behavior of certain states:taskResourceLocalHandlers?
: An object that overrides the resource of the specifiedTask
states to run a local function.waitTimeOverrides?
: An object that overrides the wait duration of the specifiedWait
states. The specified override duration should be in milliseconds.retryIntervalOverrides?
: An object that overrides the pause duration of the specified state'sRetry
field. The specified override duration should be a number in milliseconds; or an array of numbers, where each number represents milliseconds.
noThrowOnAbort?
: If this option is set totrue
, aborting the execution will simply returnnull
as result instead of throwing.context?
: An object that will be used as the Context Object for the execution. If not passed, the Context Object will default to the following object:This option is useful to mock the fields of the Context Object in case your definition references it in a JSONPath.{ "Execution": { "Input": /* input passed to the execution */, "StartTime": /* ISO 8601 timestamp of when the execution started */ } }
Returns an object that has the following properties:
result
: APromise
that resolves with the result of the execution, if it ends successfully.abort
: A function that takes no parameters and doesn't return any value. If called, aborts the execution and throws anExecutionAbortedError
, unless thenoThrowOnAbort
option is set.eventLogs
: AnAsyncGenerator
that produces a log of events as the execution runs. To learn more about the events, their type, and their format, see the following document.
import { StateMachine } from 'aws-local-stepfunctions';
const machineDefinition = {
StartAt: 'Hello World',
States: {
'Hello World': {
Type: 'Task',
Resource: 'arn:aws:lambda:us-east-1:123456789012:function:HelloWorld',
End: true,
},
},
};
const stateMachine = new StateMachine(machineDefinition);
const myInput = { value1: 'hello', value2: 123, value3: true };
const execution = stateMachine.run(myInput); // execute the state machine
const result = await execution.result; // wait until the execution finishes to get the result
console.log(result); // log the result of the execution
In addition to the JavaScript API, aws-local-stepfunctions
also provides a command-line interface. The CLI allows you to run one or several executions without having to create a Node.js script.
To use the CLI as a global shell command, you need to install the package globally:
npm install -g aws-local-stepfunctions
After installing the package, the command local-sfn
will be available in your shell.
The simplest way to use the CLI is by passing either the -d, --definition
or the -f, --definition-file
option, along with the input(s) for the state machine. For example:
local-sfn \
-f state-machine.json \
'{ "num1": 1, "num2": 2 }' \
'{ "num1": 3, "num2": 4 }' \
'{ "num1": 5, "num2": 6 }'
This command would execute the state machine defined in file state-machine.json
with '{ "num1": 1, "num2": 2 }'
, '{ "num1": 3, "num2": 4 }'
, and '{ "num1": 5, "num2": 6 }'
as inputs. Each input corresponds to a state machine execution, and each execution is run independently, so the failure of one execution doesn't mean the failure of all of the other executions.
Now, suppose the state machine in file state-machine.json
is defined as a single Task
state that calls a Lambda function that adds num1
and num2
:
{
"StartAt": "AddNumbers",
"States": {
"AddNumbers": {
"Type": "Task",
"Resource": "arn:aws:lambda:us-east-1:123456789012:function:AddNumbers",
"End": true
}
}
}
Then, the output of the local-sfn
command above may look something like this:
3
7
11
Note that each line of the output corresponds to the result of each input, in the same order that the inputs were given to the command.
local-sfn
can also read the execution input from the standard input.
If the first line of stdin can be parsed as a single JSON value, then local-sfn
will consider each line as an input. Otherwise, the entire stdin will be considered as a single JSON input.
For example, assume you have the following text file, called inputs.txt
, and you want to pass the contents of the file as inputs to local-sfn
:
{ "num1": 1, "num2": 2 }
{ "num1": 3, "num2": 4 }
{ "num1": 5, "num2": 6 }
Because the first line is parsable as JSON, local-sfn
will process each line as a single input.
You can then run the following command to pass the inputs of the text file to local-sfn
:
cat inputs.txt | local-sfn -f state-machine.json
Alternatively, using input redirection:
local-sfn -f state-machine.json < inputs.txt
On the other hand, assume you have this additional file, called input.json
:
{
"num1": 5,
"num2": 3
}
If you pass this file as input, local-sfn
will automatically detect that it is a single, multiline JSON value and process it as a single value.
As explained in the Feature support document, it's possible to override the default actions of Task
states and Wait
states.
To override a Task
state, pass the -t, --override-task
option. This option takes as value the name of the Task
state you want to override, and a path to a script or program that will be executed instead of the resource specified in the state definition. The state name and the path must be separated by a colon :
.
Using the same state machine definition as before, if you wanted to override the AddNumbers
state to run a custom script, you can do it like this:
local-sfn -f state-machine.json -t AddNumbers:./override.sh '{ "num1": 1, "num2": 2 }'
This command would run the state machine, but instead of invoking the Lambda function specified in the Resource
field of the AddNumbers
state, the override.sh
script would be executed.
Now, suppose the override.sh
script is defined like this:
#!/bin/sh
TASK_INPUT=$1 # First argument is the input to the overridden Task state
echo "$TASK_INPUT" | jq '.num1 + .num2' # Use jq to add "num1" and "num2", and print result to stdout
When overriding a Task
state, the overriding executable will be passed the input to the Task
state as first argument, which can then be used to compute the task result. Similarly, the executable must print the task result as a JSON value to the standard output, so local-sfn
can then read stdout and use the value as the result of the Task
state. If the executable terminates with an exit code different from 0
, its standard error will be printed and the execution will be marked as a failure.
Additionally, you can pass the -t, --override-task
option multiple times, to override more than one Task
state. For example:
local-sfn
-f state-machine.json \
-t AddNumbers:./override.sh \
-t SendRequest:./request.py \
-t ProcessImage:./proc_image \
'{ "num1": 1, "num2": 2 }'
This command would execute the state machine, and override Task
states AddNumbers
, SendRequest
, and ProcessImage
to run the override.sh
shell script, the request.py
Python script, and the proc_image
program, respectively.
To override the duration of a Wait
state, pass the -w, --override-wait
option. This option takes as value the name of the Wait
state you want to override, and a number that represents the amount in milliseconds that you want to pause the execution for. The state name and the milliseconds amount must be separated by a colon :
.
For example:
local-sfn -f state-machine.json -w WaitResponse:1500 '{ "num1": 1, "num2": 2 }'
This command would execute the state machine, and when entering the WaitResponse
Wait
state, the execution would be paused for 1500 milliseconds (1.5 seconds), disregarding the Seconds
, Timestamp
, SecondsPath
, or TimestampPath
fields that could've been specified in the definition of WaitResponse
.
In the same way as the -t, --override-task
option, you can pass the -w, --override-wait
option multiple times, to override more than one Wait
state. For example:
local-sfn \
-f state-machine.json \
-w WaitResponse:1500 \
-w PauseUntilSignal:250 \
-w Delay:0 \
'{ "num1": 1, "num2": 2 }'
This command would execute the state machine, and override Wait
states WaitResponse
and PauseUntilSignal
to pause the execution for 1500 and 250 milliseconds, respectively. The Delay
state wouldn't be paused at all, since the override value is set to 0.
To override the duration of the pause in the Retry
field of a state, pass the -r, --override-retry
option. This option takes as value the name of the state whose Retry
field you want to override, and a number that represents the amount in milliseconds that you want to pause the execution for before retrying the state. The state name and the milliseconds amount must be separated by a colon :
.
For example, suppose the state machine definition contains a state called TaskToRetry
that is defined as follows:
{
"Type": "Task",
"Resource": "arn:aws:lambda:us-east-1:123456789012:function:HelloWorld",
"Retry": [
{ "ErrorEquals": ["States.Timeout", "SyntaxError"] },
{ "ErrorEquals": ["RangeError"] },
{ "ErrorEquals": ["States.ALL"] }
],
"End": true
}
Then, the following command is run:
local-sfn -f state-machine.json -r TaskToRetry:100 '{ "num1": 1, "num2": 2 }'
This command would execute the state machine, and if the TaskToRetry
state fails, the execution would be paused for 100 milliseconds before retrying the state again, disregarding the IntervalSeconds
, BackoffRate
, MaxDelaySeconds
, and JitterStrategy
fields that could've been specified in any of the Retry
field retriers.
Alternatively, you can also pass a list of comma-separated numbers as value, to override the duration of specific retriers, for instance:
local-sfn -f state-machine.json -r TaskToRetry:100,-1,20 '{ "num1": 1, "num2": 2 }'
The above command would pause the execution for 100 milliseconds if the state error is matched by the first retrier and it would pause for 20 milliseconds if the error matches the third retrier. Note that a -1 was passed for the second retrier. This means that the pause duration of the second retrier will not be overridden, instead, it will be calculated as usually with the IntervalSeconds
and the other retrier fields, or use the default values if said fields are not specified.
Furthermore, you can pass this option multiple times, to override the Retry
fields in multiple states. For example:
local-sfn \
-f state-machine.json \
-r SendRequest:1500 \
-r ProcessData:250 \
-r MapResponses:0 \
'{ "num1": 1, "num2": 2 }'
This command would execute the state machine, and override the duration of the retry pause in states SendRequest
and ProcessData
to pause the execution for 1500 and 250 milliseconds, respectively. The retry in the MapResponses
state wouldn't be paused at all, since the override value is set to 0.
If the JSONPaths in your definition reference the Context Object, you can provide a mock Context Object by passing either the --context
or the --context-file
option. For example, given the following definition:
{
"StartAt": "Get execution context data",
"States": {
"Get execution context data": {
"Type": "Pass",
"Parameters": {
"execId.$": "$$.Execution.Id",
"execName.$": "$$.Execution.Name"
},
"End": true
}
}
}
And given the following context.json
file:
{
"Execution": {
"Id": "arn:aws:states:us-east-1:123456789012:execution:stateMachineName:executionName",
"Name": "executionName"
}
}
You could provide the Context Object to the execution in the following manner:
local-sfn \
-f state-machine.json \
--context-file context.json \
'{}'
Before attempting to run the state machine with the given inputs, the state machine definition itself is validated to check that:
- JSONPath strings are valid.
- ARNs in the
Resource
field ofTask
states are valid. - There are no invalid fields.
- All states in the definition can be reached.
If any of these checks fail, local-sfn
will print the validation error and exit. To partially suppress this behavior, you can pass the --no-jsonpath-validation
option, to suppress JSONPath validation; and the --no-arn-validation
option, to suppress ARN validation.
Alternatively, if you want to completely disable all validations, you can pass the --no-validation
option. Be aware that passing this option implies no guarantees if the provided definition is invalid or contains non-standard fields: running it might result in undefined/unsupported behavior, so use at your own risk.
local-sfn
can terminate with the following exit codes:
Exit code | Explanation |
---|---|
0 | The state machine was executed, and all executions ran successfully. |
1 | An error occurred before the state machine could be executed (e.g. a parsing error). |
2 | The state machine was executed, but at least one execution had an error. |
You can check more examples and options usage in the examples directory.
To run the examples, clone the repo, install the dependencies and build the project:
git clone https://github.com/nibble-4bits/aws-local-stepfunctions.git --depth 1
cd aws-local-stepfunctions
npm install
npm run build
Then run whichever example you want:
node examples/abort-execution.js