Workflow::awaitWithTimeout() currently accepts a timeout interval and conditions, but does not allow passing AwaitOptions.
Internally, WorkflowContext::awaitWithTimeout() already creates an AwaitOptions instance:
$request = new NewTimer(
new AwaitOptions($input->interval, null)
);
It would be useful to expose this option through the public API instead of always creating it with null.
One important use case is providing TimerOptions for the underlying timer, especially its summary.
For example, when multiple awaitWithTimeout() calls are running concurrently, such as inside Workflow::async(), it can be difficult to identify the corresponding timers in the Temporal UI:
$rtdsReceived = yield Workflow::awaitWithTimeout(
CarbonInterval::seconds(30),
fn (): bool => $this->signal->receiveRtdsResolution !== null,
);
$webSocketReceived = yield Workflow::awaitWithTimeout(
CarbonInterval::minutes(3),
fn (): bool => $this->signal->receiveWebSocketResolution !== null,
);
It would be useful to have an API along the lines of:
$rtdsReceived = yield Workflow::awaitWithTimeout(
CarbonInterval::seconds(30),
fn (): bool => $this->signal->receiveRtdsResolution !== null,
AwaitOptions::new()->withTimerOptions(
TimerOptions::new()->withSummary('rtds-resolution-wait'),
),
);
or
$rtdsReceived = yield Workflow::awaitWithTimeout(
AwaitOptions::new()->withTimerOptions(
CarbonInterval::seconds(30),
TimerOptions::new()->withSummary('rtds-resolution-wait'),
),
fn (): bool => $this->signal->receiveRtdsResolution !== null,
);
Or any equivalent API that allows AwaitOptions to be supplied.
The main point is that awaitWithTimeout() already uses AwaitOptions internally, so exposing AwaitOptions would allow additional await-related options to be added in the future without repeatedly changing the awaitWithTimeout() API.
In particular, this would allow the underlying timer to use TimerOptions, consistent with the existing Workflow::timer() API.
This would improve the observability of concurrent awaitWithTimeout() operations in the Temporal UI without requiring users to replace awaitWithTimeout() with custom timer logic.
Workflow::awaitWithTimeout()currently accepts a timeout interval and conditions, but does not allow passingAwaitOptions.Internally,
WorkflowContext::awaitWithTimeout()already creates anAwaitOptionsinstance:It would be useful to expose this option through the public API instead of always creating it with
null.One important use case is providing
TimerOptionsfor the underlying timer, especially itssummary.For example, when multiple
awaitWithTimeout()calls are running concurrently, such as insideWorkflow::async(), it can be difficult to identify the corresponding timers in the Temporal UI:It would be useful to have an API along the lines of:
or
Or any equivalent API that allows
AwaitOptionsto be supplied.The main point is that
awaitWithTimeout()already usesAwaitOptionsinternally, so exposingAwaitOptionswould allow additional await-related options to be added in the future without repeatedly changing theawaitWithTimeout()API.In particular, this would allow the underlying timer to use
TimerOptions, consistent with the existingWorkflow::timer()API.This would improve the observability of concurrent
awaitWithTimeout()operations in the Temporal UI without requiring users to replaceawaitWithTimeout()with custom timer logic.