Activity local dispatch #2618
Activity local dispatch #2618
Conversation
| return nil, nil | ||
| } | ||
|
|
||
| if _, err := handler.mutableState.AddActivityTaskStartedEvent( |
There was a problem hiding this comment.
does server control how many activities are allowed for local dispatch? or all of them as SDK asked?
There was a problem hiding this comment.
Synced offline. Currently there's no obvious reason for server to reject the request (even if the activity is scheduled cross namespace or on a different task queue). The workflow mutable state update transaction and history have the same size.
If worker set request_start to true, then it should guarantee it is able to run that activity.
| // RetryPolicy: TODO: do we need this field? | ||
| // not specified by matching or frontend as well |
There was a problem hiding this comment.
it seems this is not used by sdk (checked sdk-go). I think we should not have this field.
There was a problem hiding this comment.
Removed the TODO. I will double check with SDK side before removing it from proto def.
What changed?
request_startto true for an activity command. If server accepts (currently server always accepts if the feature is enabled for that namespace) the request, then the activity will be scheduled AND started, and be returned to the sdk in respondWorkflowTaskResponse.request_startis true, it's has the capacity and is able to run the activity (even if it's cross-namespace or on a different task list)Why?
How did you test it?
Potential risks
Is hotfix candidate?