Support `fmt.Stringer` in `ExecuteActivity`

[LukaGiorgadze]

PR: #2050

Support fmt.Stringer in getFunctionName

Description

Currently, getFunctionName only supports raw strings or function pointers.
If a caller passes a custom type that implements fmt.Stringer (e.g. a named type alias), it is treated as a function and causes error and hard to get the idea why:

INF log/with_logger.go:45 Task processing failed with error Namespace=default TaskQueue=chat-agent WorkerID=28030@Lukas-MacBook-Pro-M4.local@ WorkerType=WorkflowWorker Error="BadScheduleActivityAttributes: ActivityType is not set on ScheduleActivityTaskCommand. ActivityID=15"

Example

type ActivityName string

func (a ActivityName) String() string {
	return string(a)
}

var agentPlannerActivity ActivityName = "AgentPlannerActivity"

fut := workflow.ExecuteActivity(ctx, agentPlannerActivity, inputs{})

[Quinn-With-Two-Ns]

Hmm, so why are you not calling your activity by the function type? and why create a type alias to the activity name?

per the docs

Input activity is either an activity name (string) or a function representing an activity that is getting scheduled.

So ExecuteActivity is only expected to be given a string of function. I agree the error your seeing is not great, we should probably fail sooner if we can't find an activity name.

[LukaGiorgadze]

Hmm, so why are you not calling your activity by the function type? and why create a type alias to the activity name?

per the docs

Input activity is either an activity name (string) or a function representing an activity that is getting scheduled.

So ExecuteActivity is only expected to be given a string of function. I agree the error your seeing is not great, we should probably fail sooner if we can't find an activity name.

Good question. I need to run activities dynamically (doing some DSL stuff). That means I can’t always call them by function pointer. I could pass plain strings or use any, but both lose type safety. Defining ActivityName gives me a safe, explicit way to pass activity names without raw strings.

Question is more like if we accept raw "string", then why not Stringer()?

[Quinn-With-Two-Ns]

Defining your activity name as a constant makes sense, the constant just needs to be of the right type. Activity name is expected to be a string everywhere else in the SDK, the only reason we take the empty interface in execute is because Go doesn't support variant types