[pcbeingused333]

Fixes #634

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Issue Link, if available

#634

Description

When waitForCondition exhausts its attempts, the built-in wait strategies (WaitStrategies.java) throw WaitForConditionFailedException(String message). That constructor called super(null, null, message), so the exception carried a null ErrorObject. WaitForConditionOperation.handleCheckFailure(), ChildContextOperation and DurableExecutor.buildErrorObject() all return getErrorObject() as-is, so the step, the enclosing child context and the root invocation ended FAILED with no error.

The fix builds the ErrorObject (error type + message) in that constructor, the same way IllegalDurableOperationException(String) does. The downstream paths then get a non-null error without any change.

Demo/Screenshots

N/A

Design

• Design note (rule 3): not needed (bug fix, no public API change).
• Simpler options considered (rule 2): the issue proposes null fallbacks in DurableExecutor.buildErrorObject(), handleCheckFailure() and ChildContextOperation. That adds a branch at three read sites; fixing the one constructor that produces the null covers all three without new branches.
• Root cause (rule 5): WaitForConditionFailedException(String) passed null as the ErrorObject.
• Net change: +7 / −1 source lines in one file; 0 public API members added or removed.

Assumptions

None about the service, Lambda or other libraries; the change is local to the SDK exception.

Decisions not covered by the issue or the design note

• errorType is WaitForConditionFailedException's class name and errorMessage is the exception message; no errorData/stackTrace, matching IllegalDurableOperationException.
• Fixed at the constructor instead of adding the null fallbacks suggested in the issue (rule 5.3: change the code at the cause).

Checklist

• I have filled out every section of the PR template
• I have thoroughly tested this change
• Every new branch has a test that fails without it (rule 4)
• For a bug fix: the description or commit order shows the regression test failing before the fix and passing after it (rule 5)
• Every edited test expectation is listed in the description, with the reason (rule 5)

Testing

Unit Tests

Yes. WaitStrategiesTest.exponentialBackoff_maxAttemptsExceeded_throwsException gains assertions that the thrown exception has a non-null ErrorObject with the expected type and message (no existing expectation edited). Without the fix it fails with expected: not <null> at line 66; with the fix mvn -pl sdk test -Dtest=WaitStrategiesTest passes (530 tests).

Integration Tests

No; the failure path downstream of the exception is unchanged.

Examples

Not applicable.

---

This change was prepared with the assistance of an AI coding tool (Claude) and submitted by the account owner.