Timeouts about eventual HOT 5 CLOSED

I wonder if it's right to attach this timeout to the thing being called rather than use a scope?

await withTimeout(1000, async() => {
  await activity1();
});

from eventual.

How will these be implemented? Will it always use a scheduled event to wake up the caller's orchestrator? Or is it case by case?

from eventual.

We will allow the configuration of two different timeouts on the child workflow to handle the ambiguity.

Why is this extra complexity needed?

from eventual.

I wonder if it's right to attach this timeout to the thing being called rather than use a scope?

await withTimeout(1000, async() => {
  await activity1();
});

This would definitely work and would allow be arbitrary timeout scopes.

I think doing the same for retry would be little more complex because the workflow would need to be involved instead of just a retry loop around the activity/workflow.

So we'll likely end up with activity/workflow call level timeout for both? Or maybe retry just stays at the definition level?

from eventual.

Being able to programatically specify the timeout of an activity when calling it is necessary.

• set timeout when calling an activity
• set timeout when returning asyncResult from activity?

from eventual.