Step function embedded workflows appear to have 2-3 second overhead

Hello,

From your query, I understand that you have created a Step Function workflow with multiple embedded workflows i.e. a nested workflow using startExecution.sync:2 and observed a delay of 2-3 seconds in the parent workflow while executing the task. However, the time spent in executing the logic in each of the embedded/nested workflow is in milli seconds. You wanted to understand if this is the expected behavior or not.

Here, I would like to inform you that when an embedded/nested workflow execution is started using .sync integration pattern [1], there is a 2-3 seconds latency observed in parent StateMachine becoming aware of nested StateMachine execution completion status. Kindly note that the internal team is aware of this issue and identified it as an expected behavior.

They are working to improve this latency in case of a .sync integration with nested StateMachines. We do not have the visibility regarding the feature's roadmap and backlog and unfortunately, we will not be able to provide an ETA on when this will be implemented. Therefore I would kindly request you to keep an eye on the what’s new page or the AWS Blogs as all new feature requests and enhancements are posted there.

[+] AWS blogs: https://blogs.amazon.com/
[+] What’s New: https://aws.amazon.com/new/
[+] AWS Release Notes: https://aws.amazon.com/releasenotes/ [+] AWS Step Functions Compute Blog: https://aws.amazon.com/blogs/compute/tag/aws-step-functions/

As a workaround to avoid this 2-3 seconds delay caused by .sync integration, we would request you to leverage .waitForTaskToken integration pattern instead of .sync integration pattern. Using .waitForTaskToken [2] integration pattern with nested StateMachine execution, eliminates the 2-3 seconds delay.

[1] https://docs.aws.amazon.com/step-functions/latest/dg/connect-to-resource.html#connect-sync [2] https://docs.aws.amazon.com/step-functions/latest/dg/connect-to-resource.html#connect-wait-token