My understanding is heartbeatTimeout may not apply to workflow but for the other 3, why workflow task does not have that granularity and instead just have workflowTaskTimeout?
Is there some assumption that a workflow task start to finish should be really fast, so one workflowTaskTimeout is enough?
Workflow task has all these timeouts, but they are not exposed to users directly in the majority of cases.
For example a process specific task queue ScheduleToStartTimeout can be configured through WorkerFactoryOptions.workflowHostLocalTaskQueueScheduleToStartTimeout. The ``ScheduleToStartTimeout` for a normal workflow task queue doesn’t apply as it doesn’t make sense to timeout a workflow task before the workflow run timeout.
Workflow tasks also kind of heartbeat every workflow task timeout interval to support local activities take longer than a configured workflow task timeout.
ScheduleToCloseTimeout doesn’t really apply to workflow tasks as they are retried up to workflow timeout.
WorkerFactoryOptions.workflowHostLocalTaskQueueScheduleToStartTimeout sounds per queue or per host to me. So we cannot specify per execution? We can specify workflowTaskTimeout when start the execution for each execution so why not scheduleToStartTimeout?
My questions are not from any solid use cases, just curiosity when I notice the workflow task and activity task do not have the same options. So thank you for reply
They play different roles. WorkerFactoryOptions.workflowHostLocalTaskQueueScheduleToStartTimeout is used to detect worker host failures and don’t depend on a specific workflow implementation.