- Newest
- Most votes
- Most comments
Hello,
Based on the information provided, here are several potential causes and debugging steps:
- Throttling Impact
- While you're correct that ExecutionThrottled errors typically don't directly cause timeouts, heavy throttling can indirectly lead to processing delays
- At 150 executions/sec, you might be hitting AWS Step Functions service quotas [+]
- The ActivityStarted state means the task was picked up, but the actual processing might have been delayed due to throttling
- Network/Connectivity Issues
- There could be intermittent network issues between Step Functions and your ECS tasks
- Since you see ActivityStarted but no application logs, the task might have been picked up but failed to maintain connection
- Task Worker Behavior
- Check if your Go worker implementation properly handles the GetActivityTask API calls
- Ensure proper error handling and task heartbeat mechanisms are in place
- Verify the worker is sending heartbeats for long-running tasks
- Recommendations:
- Implement exponential backoff for throttling
- Consider reducing concurrent executions
- Implement robust error handling and retry mechanisms
- Use Step Functions service integrations where possible instead of activities
- Monitor task tokens and heartbeat mechanisms
Additionally, to further investigate and address your question, we require details that are non-public information like execution history and step function definition to troubleshooting further. Please open a support case with AWS using the following link
[+] https://console.aws.amazon.com/support/home#/case/create
answered a year ago
There are several potential reasons why your Step Function activity reached the ActivityStarted state but wasn't processed by your ECS application, leading to an ActivityTimedOut error. Here are some possibilities and suggestions for further debugging:
-
Network issues: There might have been temporary network connectivity problems between AWS Step Functions and your ECS tasks. This could prevent the activity task from reaching your application, even though it was marked as started.
-
ECS task capacity: During your high-throughput benchmark, your ECS cluster might have reached its capacity limit, preventing new tasks from being launched to handle the incoming activities.
-
Activity worker overload: Your Go application might be overwhelmed with the number of concurrent requests, causing some activities to be queued for longer than the timeout period.
-
Improper timeout configuration: Ensure that the timeout set for your activities in the Step Functions state machine definition is sufficient for your workload, especially during high-concurrency scenarios.
-
SDK configuration: The aws-sdk-go library might be experiencing issues with connection pooling or timeout settings, causing some requests to be dropped or delayed.
To debug this further:
-
Enable detailed CloudWatch logging for your Step Functions if you haven't already. This can provide more insight into the exact timing and nature of the timeout.
-
Implement more granular logging in your Go application, including timestamps for when activities are received and completed.
-
Monitor your ECS cluster metrics closely, paying attention to CPU utilization, memory usage, and network performance.
-
Review the configuration of your aws-sdk-go implementation, ensuring that connection pooling and timeout settings are optimized for your workload.
-
Consider implementing a custom metric or log entry in your application to track the time between receiving an activity task and starting to process it. This can help identify if there's a queue building up in your application.
-
Analyze the pattern of timeouts. If they consistently occur after a certain number of concurrent executions, it might indicate a capacity or rate limit issue.
-
If possible, implement distributed tracing (e.g., with AWS X-Ray) to get a more detailed view of the request flow from Step Functions to your application.
By investigating these areas and implementing more detailed monitoring and logging, you should be able to pinpoint the root cause of the activity timeouts and take appropriate action to prevent them in future high-concurrency scenarios.
Sources
StepFunction wait state waiting for more than the requested wait time | AWS re:Post
StepFunction invocation taking more than 2 second | AWS re:Post
Best practices for Step Functions - AWS Step Functions
[Exception: AWS::Flow::ActivityTaskTimedOutException
— AWS Flow Framework for Ruby - API Reference (version 2.0)](https://docs.aws.amazon.com/amazonswf/latest/awsrbflowapi/AWS/Flow/ActivityTaskTimedOutException.html)
Troubleshooting issues in Step Functions - AWS Step Functions
answered a year ago
Relevant content
- AWS OFFICIALUpdated 3 years ago

Hi
About this, what exactly does it mean by actual processing here? Does activityStarted to processing stage also count as state transition?
But even if connection was broken, shouldn't I find logs of GetActivityTask in my application?
I send heartbeat every 30 seconds for each activity worker. The timeout of the activity is 65 seconds. Should I change the heartbeat interval?
Also, can I configure any kind of alert if my step-function is timed-out out?