fix: DurableFuture.anyOf blocking without deregistering the active thread

[hln33]

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

#707

Description

Fixes DurableFuture.anyOf suspension handling.

Previously anyOf waited on CompletableFuture.anyOf(...).join() directly from the durable context thread. If none of the candidate durable operations could settle in the current invocation, that thread stayed registered as active, so the execution manager never observed an idle execution and could not suspend.

This change routes first-completion waits through SDK thread coordination:

• DurableFuture.anyOf now validates that at least one SDK-created durable future is provided, converts those futures to BaseDurableOperations, waits for the first operation to settle, and returns that operation's result.
• BaseDurableOperation.waitForFirstOperationCompletion(...) and ExecutionManager.waitForFirstOperationCompletion(...) provide the multi-operation equivalent of get(): the caller thread deregisters while waiting, is re-registered when the first operation settles successfully, and suspension/failure paths propagate through the existing execution error handling.
• Single-operation waiting was moved into ExecutionManager.waitForOperationCompletion(...) so get() and anyOf() share the same manager-owned coordination model.
• Operation completion locking is now owned by ExecutionManager, including the existing parent-lock behavior for map/parallel child operations, so checkpoint state publication and completion-future notification remain serialized with waiter registration.
• First-completion waits reject null/empty inputs, non-SDK futures, operations from different execution managers, and nested waits from step threads.

Demo/Screenshots

n/a

Checklist

• I have filled out every section of the PR template
• I have thoroughly tested this change

Testing

Automated coverage was added/updated for the new first-completion path and the original suspension regression. GitHub checks for this commit are currently pending.

Unit Tests

• Added BaseDurableOperationFirstCompletionTest coverage for input validation, same-manager validation, step-thread rejection, already-settled operations, suspension while no operation can settle, caller reactivation after a later settlement, reactivation-before-return ordering, and suspension propagation.
• Added DurableFutureTest coverage for anyOf empty/null input and non-SDK future validation.
• Updated ExecutionManagerTest coverage around manager-owned completion locks, checkpoint update atomicity, single-operation waiter reactivation, deferred suspension, and checkpoint delivery ordering.
• Updated operation unit tests and shared mocks to use the manager-owned completion coordination.

Integration Tests

• Added DurableFutureAnyOfSuspensionTest with local durable-runner coverage for future.get(), DurableFuture.allOf(...), and DurableFuture.anyOf(...) suspending instead of leaving the execution blocked.

Manual E2E Test

• Deployed a real Lambda Durable Function that uses DurableFuture.anyOf() and 2 async callback operations
• Verified that the function does not constantly invocation timeout when all callbacks are pending which was the prior behaviour
  • Since the function was not suspending, the lambda continued running until invocation timeout

Screenshots

Before and after screenshots below.

Note that the before has an invocation timeout immediately after both callbacks are submitted. This is because execution is not suspending and instead runs until timeout.

Both before and after show multiple invocation timeouts after the first callback resolves. This is a separate issue tracked under #734.

Before

After

[hln33]

This is the new lock logic that reviewers should pay extra attention to.

[github-actions]

Codex AI review · Finding arf_v1_4hw3zgpptmxeatdkdawqqh6a3f

[P1] Publish the final child completion lock before registration

For map/parallel children, the preceding registeredOperations.put(...) makes the operation visible before these lines install its parent lock. A concurrent checkpoint can create and use a child-local lock, which is then replaced here. Consequently, get() may check and attach its callback under a different lock from completion; completion between those actions registers the still-active caller, and the following deregistration leaves it inactive, permitting premature suspension. Install the final lock before publishing the operation to registeredOperations (or make both publications atomic), and add a child-registration/checkpoint race test.

[github-actions]

Codex AI review

Found one high-severity thread-coordination race in child-operation registration.

Reviewed commit 16a32a4c34b03f42131862d999a1c6588c91dd17. Workflow run