fix(testing): handle workflow failure states correctly

[hln33]

Issue #, if available:
#656

Description of changes:

• Modify handling of failed invocations to authoratively call self._fail_workflow() instead of self._complete_workflow() so that executions fail despite not having an error payload
  • Confirmed against the real backend service that failed invocations without error payloads should result in a failed execution
  • Prior to this change, failed invocations with no error payloads would result in a successful execution
• Add tests covering the following behavior (requested in [Bug]: FAILED invocation without ErrorObject is completed as SUCCEEDED by local emulator #656):
  • A failed invocation results in a failed execution
  • Caught Child context failures do not cause execution failure

Testing:

• Ran all tests in package via hatch run test:all
• Invoked SAM CLI with local emulator changes and a reproducing Java durable function. This confirms failed invocations with empty error payloads result in failed execution:

sam local invoke WaitForConditionChildFailureJavaFunction

...

Execution Summary:
=========================
ARN:      31d25a2e-2e37-4bea-b67e-02441a5fa80c/55c89648-9aca-4b8e-8147-f01658dabf0a                                                                           Name:     N/A                                                                  Duration: 6.58s
Status:   FAILED ❌
Input:    {}

Commands you can use next
=========================
[*] Get execution details: sam local execution get 31d25a2e-2e37-4bea-b67e-02441a5fa80c/55c89648-9aca-4b8e-8147-f01658dabf0a
[*] View execution history: sam local execution history 31d25a2e-2e37-4bea-b67e-02441a5fa80c/55c89648-9aca-4b8e-8147-f01658dabf0a

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[yaythomas]

Very nice, thank you! just some nits.

[hln33]

I do not think "ABORTED" is a valid execution status. Could not find any references to it in other SDKs. The API documentation also does not list "ABORTED" as being a valid execution status.

I think it should instead be "STOPPED", as that specific status is not covered in this function.

I noticed this when implementing a new "execution_status" field on the test result class and my AI coding agent flagged this to me.

[github-actions]

Codex AI review

No actionable findings. Residual risk is limited to runtime validation because tests were not executed under the review constraints.

Reviewed commit d8badbeb9c64d9256e556361cd6534e8e9a48eca. Workflow run

[yaythomas]

friendly reminder to squash at merge with a conventional-commits message (lint-commits is currently red only because of the squash: markers).