Quinn Klassen

Hi @pragnareddye , thank you for the contribution. I need to go over this more tomorrow, but it would be helpful if we also add some test with this change...

we should also verify If both [setScheduleToCloseTimeout(Duration)](https://www.javadoc.io/static/io.temporal/temporal-sdk/1.20.0/io/temporal/activity/LocalActivityOptions.Builder.html#setScheduleToCloseTimeout(java.time.Duration)) and [RetryOptions.Builder.setMaximumAttempts(int)](https://www.javadoc.io/static/io.temporal/temporal-sdk/1.20.0/io/temporal/common/RetryOptions.Builder.html#setMaximumAttempts(int)) are not set, the Activity will not be retried.

Unlikely this would be taken forward, the intention is users deduce the message from the exception type and changing the message would be a backwards incompatible change to `WorkflowExecutionAlreadyStarted`.

There is already a fix merged for this https://github.com/temporalio/sdk-go/commit/72a5b6fbc0831183fb69d0debb560fdbfc6a8fdb. We will release a `v0.2.0` after the Go SDK is released.

Yes it will be

Closing since workflowcheck v0.2.0 is released https://github.com/temporalio/sdk-go/releases/tag/contrib%2Ftools%2Fworkflowcheck%2Fv0.2.0

@cretz didn't you fix this here https://github.com/temporalio/sdk-go/issues/882?

@cretz I believe this is resolved now since [loadCapabilities](https://github.com/temporalio/sdk-go/blob/master/internal/internal_workflow_client.go#L1216) now takes the context and it is wired up in all possible locations we could.

related: https://github.com/temporalio/sdk-go/issues/1349

> Most, including Go, support wrapping the result from start to customize result fetching Go does not support intercepting `client.GetWorkflow` so you cannot always wrap automatically wrap `WorkflowResult`. If we...