Describe the bug
Go SDK would time out an activity if the activity type is unknown (not registered) to the worker. Activity worker would silently fail the tasks and let the activity time out on the server.
The behavior is different in Java SDK, which would respond failures immediately.
Cause is due to:
func (atp *activityTaskPoller) ProcessTask(task interface{}) error {
// Process the activity task.
request, err := atp.taskHandler.Execute(atp.taskList.GetName(), activityTask.task)
if err != nil {
metricsScope.Counter(metrics.ActivityExecutionFailedCounter).Inc(1)
return err // <- silent failure on SDK with loggings only
}
|
// Process the activity task. |
|
request, err := atp.taskHandler.Execute(atp.taskList.GetName(), activityTask.task) |
To Reproduce
Is the issue reproducible?
Steps to reproduce the behavior:
Start both Cadence activity worker and workflow worker. Start a simple registered workflow that executes one unregistered activity. Activity would hang in workflow history and eventually timeout.
Expected behavior
Activity should fail instead with error message (activity not registered)
Screenshots
N/A
Additional context
N/A
Describe the bug
Go SDK would time out an activity if the activity type is unknown (not registered) to the worker. Activity worker would silently fail the tasks and let the activity time out on the server.
The behavior is different in Java SDK, which would respond failures immediately.
Cause is due to:
cadence-go-client/internal/internal_task_pollers.go
Lines 1166 to 1167 in 70ea3b3
To Reproduce
Is the issue reproducible?
Steps to reproduce the behavior:
Start both Cadence activity worker and workflow worker. Start a simple registered workflow that executes one unregistered activity. Activity would hang in workflow history and eventually timeout.
Expected behavior
Activity should fail instead with error message (activity not registered)
Screenshots
N/A
Additional context
N/A