fix(testing): handle workflow failure states correctly by hln33 · Pull Request #682 · aws/aws-durable-execution-sdk-python

hln33 · 2026-08-25T22:56:30Z

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.

hln33 · 2026-08-26T00:23:48Z

Sign in to view

-                self._complete_workflow(
-                    execution_arn, result=None, error=response.error
-                )
+                self._fail_workflow(execution_arn, response.error)


There is one small obstacle to doing that. There currently isn't anything in the public API of DurableFunctionTestRunner or DurableFunctionTestResult that exposes an execution's status in the emulator. The public runner result only exposes the returned durable invocation status/result, not execution.

We could use private internals, like DurableFunctionTestRunner._executor, to get execution information, but that feels hacky to me for an e2e style test.

If we want to add an e2e test for this case, then I think we should first add a small public runner accessor for execution details/status, then use that in the test.

I feel like we should expose a method for the overall execution status on the test runner here. Do we have this in the TS testing library? Thinking something like result.execution_status?

nice idea @bchampp :-)

result.execution_status sourced from close_status

github-actions · 2026-08-26T00:27:39Z

Codex AI review

No actionable findings. Tests were not run per review constraints; residual risk is limited to unexecuted runtime integration coverage.

Reviewed commit 09acaf6e6ed15e233c6a5deb0bcbda15034fe888. Workflow run

bchampp · 2026-08-26T00:37:55Z

-                self._complete_workflow(
-                    execution_arn, result=None, error=response.error
-                )
+                self._fail_workflow(execution_arn, response.error)


I feel like we should expose a method for the overall execution status on the test runner here. Do we have this in the TS testing library? Thinking something like result.execution_status?

yaythomas

Very nice, thank you! just some nits.

yaythomas · 2026-08-26T03:55:13Z

+    stored = store.load(execution.durable_execution_arn)
+    assert stored.is_complete is True
+    assert stored.close_status is not None
+    assert stored.close_status.value == "FAILED"


you can compare enums directly

assert stored.close_status is ExecutionStatus.FAILED

yaythomas · 2026-08-26T03:55:38Z

+    assert stored.close_status is not None
+    assert stored.close_status.value == "FAILED"
+    assert stored.result is not None
+    assert stored.result.status == InvocationStatus.FAILED


assert stored.result.status is InvocationStatus.FAILED

yaythomas · 2026-08-26T03:56:51Z

+    assert result.result == json.dumps("handled")
+
+    child_op: ContextOperation = result.get_context("failing-child")
+    assert child_op.status == OperationStatus.FAILED


child_op.status is OperationStatus.FAILED

yaythomas · 2026-08-26T03:57:43Z

+    execution.complete_fail(None)
+
+    assert execution.is_complete is True
+    assert execution.result.status == InvocationStatus.FAILED


execution.result.status is InvocationStatus.FAILED

yaythomas · 2026-08-26T04:00:04Z

-                self._complete_workflow(
-                    execution_arn, result=None, error=response.error
-                )
+                self._fail_workflow(execution_arn, response.error)


nice idea @bchampp :-)

result.execution_status sourced from close_status

yaythomas · 2026-08-26T04:10:08Z

        self.complete_execution(execution_arn, result)

-    def on_failed(self, execution_arn: str, error: ErrorObject) -> None:
+    def on_failed(self, execution_arn: str, error: ErrorObject | None) -> None:


This type widening is right, and it exposes a pre-existing emulator divergence... Common typing W.

The checkpoint EXECUTION FAIL processor (checkpoint/processors/execution.py) synthesizes a generic ErrorObject when the update has no error, but it should instead preserve null there.

Proposal: remove the synthetic fallback, and widen ExecutionNotifier.notify_failed + ExecutionObserver.on_failed to ErrorObject | None to match the widened null signature.

hln33 deployed to ai-pr-review-runtime August 25, 2026 22:56 — with GitHub Actions Active

hln33 marked this pull request as draft August 25, 2026 22:56

hln33 force-pushed the fix/656-emulator-null-invocation-error-causes-successful-execution branch from f4129a2 to b6a604a Compare August 25, 2026 22:59

hln33 had a problem deploying to ai-pr-review August 25, 2026 23:06 — with GitHub Actions Error

hln33 force-pushed the fix/656-emulator-null-invocation-error-causes-successful-execution branch from b6a604a to 861756a Compare August 25, 2026 23:20

hln33 had a problem deploying to ai-pr-review August 25, 2026 23:20 — with GitHub Actions Error

fix(testing): handle workflow failure states correctly

09acaf6

hln33 force-pushed the fix/656-emulator-null-invocation-error-causes-successful-execution branch from 861756a to 09acaf6 Compare August 25, 2026 23:22

hln33 deployed to ai-pr-review August 25, 2026 23:22 — with GitHub Actions Active

hln33 had a problem deploying to ai-pr-review-runtime August 25, 2026 23:35 — with GitHub Actions Failure

hln33 deployed to ai-pr-review-runtime August 25, 2026 23:35 — with GitHub Actions Active

github-actions Bot reviewed Aug 25, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

hln33 marked this pull request as ready for review August 26, 2026 00:24

hln33 deployed to ai-pr-review-runtime August 26, 2026 00:24 — with GitHub Actions Active

hln33 had a problem deploying to ai-pr-review-runtime August 26, 2026 00:24 — with GitHub Actions Failure

bchampp approved these changes Aug 26, 2026

View reviewed changes

yaythomas requested changes Aug 26, 2026

View reviewed changes

Uh oh!

Conversation

hln33 commented Aug 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as outdated.

Uh oh!

hln33 Aug 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

github-actions Bot commented Aug 26, 2026

Codex AI review

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yaythomas left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

hln33 commented Aug 25, 2026 •

edited

Loading

hln33 Aug 26, 2026 •

edited

Loading