Step functions get_execution_history

[jabrennem]

Hi, This is not a bug. I just saw on the service coverage page, that step function boto3 client wasn't completely covered. I couldn't find an open issue for it, but I am curious if there is a timeline for boto3.client("stepfunctions").get_execution_history() or if that has been mentioned before? I use this method for reporting, and it would be a lot easier to mock through moto.

[bblommers]

Thanks for raising this @jabrennem! Features are generally added by the community itself, so whenever someone needs it - there's not really a timeline that we work with.

Will mark this as an enhancement.

[ciaransweet]

Hey @bblommers I've found myself in a situation where get_execution_history() would be handy to have. I've done a few Step Function contributions but trying to decide what kind of size this piece of functionality would be to implement.

Do you perhaps have any thoughts on a way to proceed? I know that currently moto just sets executions to 'RUNNING' and that we don't measure events or keep track of them, which leads me to thing this might be pretty big...

[bblommers]

Hi @ciaranevans, in the spirit of 'something is better than nothing', creating a list of events and only tracking start/stop events would be a good start. IMO, that could be a relatively small piece of work.

Required changes to make that happen:

• Store executions in the StateMachine-class (instead of in an unfiltered list in the StepFunctionsBackend)
• Move start/stop functionality in the StateMachine-class
• Track execution events in the StateMachine-class

More advanced functionality can be implemented down the road, if time is an issue. For example:

Version 2.0 could mimick a successful execution, by changing the status to 'SUCCEEDED' after say the 3rd 'get-execution-history' invocation. The same technique is already used in the Transcribe-service: https://github.com/spulec/moto/pull/3299/files#diff-0297ad13d08f2d965600fdea42e6586509a141db019fbf79dfb49de2bd2c8076R260

Version 3.0 could introduce the 'timed out' status, in the same way: check the execution.start_time when advancing the execution-status.

[ciaransweet]

Hey @bblommers, thanks for the info! The fake status changing sounds positive. I wonder if we could set an environment variable for moto so that we could determine whether we fake just successes or have failures too (we're writing some error handling monitoring, hence the need for some errors in the mix). I'm not sure if that fits into the current state of play in the packages usage.

Many thanks for the list of changes for the first stab. I think I'll take a look at starting that imminently!

[ciaransweet]

@jabrennem are you still interested in this functionality? I'd like to try and cover your usecases too in a first stab at this 😄

[ciaransweet]

@bblommers what are your thoughts on what events we mimic? I guess the can of worms we're opening here is how much do we just fake and let people accept that it's what moto provides?

I.E - Are we happy with just a random hard coded list returned? Perhaps one which is successful, one which contains a failure?

Both options implementing your changing status after X calls to get-execution-history?

[ciaransweet]

I've thought about it a bit more, I think the best option for now is to provide a history of a successful invocation which is hardcoded, and one that is a history of a failed execution.

I'll provide this difference via an ENV var flag which someone can always wrap their test with to determine which history they get.

[bblommers]

@ciaranevans It's been awhile since I've looked at a real-life example of the events, so I can't give a lot of detail. My preference though would be a list of successful events only, and let people mock a happy path.

At a later stage maybe we can have an env variable where you can set the percentage of failures, or a chance that an execution returns a failure.

[bblommers]

Looks like our responses crossed there, but looks like GMTA :)

[ciaransweet]

Hah, happy days! I'm only planning on adding the failure case as an option as that was our main use-case for use adding this functionality, but I figured 99% of folks will want the happy path 😄 I'll ping you when the PR's ready and you can judge if it's OK!

[bblommers]

With #3507, an initial implementation of this function is now available as of moto >= 1.3.16.dev156.

Will keep this issue open to track further enhancements, as it's quite a static implementation for now.

[bblommers]

We now have a proper SFN Parser, as of Moto >= 5.0.4.dev17.

It is disabled by default, but enabled with a simple configuration: @mock_aws(config={"stepfunctions": {"execute_state_machine": True}})

This functionality was taken from LocalStack, who developed an in-memory pure Python parser. It supports calls to other services and most of the SFN features like waits, retries, catch, etc.

Please try it out! And let us know if you run into any issues.