[RaphaelFakhri]

What was changed

WorkflowStub::getCloseEvent() no longer throws TimeoutException before it reads the history response. The remaining timeout check moves to the loop condition, so it runs only when another long poll is needed (empty history or continue-as-new). A response that already holds the close event is returned.

Why?

getCloseEvent() measures each long poll with time() in whole seconds. When the remaining timeout reaches 0, it throws TimeoutException('Unable to wait for workflow completion, deadline reached') and discards the response, even if the response contains the completed, failed, or canceled event.

With getResult(timeout: 1), a workflow that completes in about 100 ms fails whenever the call crosses a second boundary, which happens on roughly 1 call in 10. Larger timeouts fail the same way when the workflow completes in the last second before the deadline.

Checklist

1. Closes [Bug] WorkflowStub::getResult() with a timeout throws TimeoutException even when the result has arrived #845

2. How was this tested:

   Two unit tests in tests/Unit/Internal/Client/WorkflowStubTestCase.php. Each mocks GetWorkflowExecutionHistory so that it returns only after the second changes:

   • testCloseEventReceivedAtDeadlineIsReturned: the response holds a completion event, and getResult(timeout: 1) returns. Before the fix it throws TimeoutException.
   • testEmptyHistoryAtDeadlineThrowsTimeoutException: the response has no events, and getResult(timeout: 1) still throws TimeoutException.

   vendor/bin/phpunit --filter "testCloseEventReceivedAtDeadlineIsReturned|testEmptyHistoryAtDeadlineThrowsTimeoutException|testEmptyHistoryContinues" tests/Unit/Internal/Client/WorkflowStubTestCase.php
   

   Before the fix: 3 tests, 1 error (TimeoutException). After the fix: 3 tests pass. php-cs-fixer and psalm report no issues on the changed source file.

3. Any docs updates needed?

   No.

[xepozz]

Good finding, thank you