Is your feature request related to a problem? Please describe.
There is no way to test the full standalone activity client flow (client → interceptor chain → worker) without spinning up a real Temporal server. TestActivityEnvironment.ExecuteActivity runs the activity function directly via taskHandler.Execute() (internal_workflow_testsuite.go:796), bypassing the ClientOutboundInterceptor chain entirely. This means user interceptors (e.g., tracing, metrics) are never invoked during tests.
Describe the solution you'd like
Add ExecuteStandaloneActivity to TestWorkflowEnvironment that goes through the full client interceptor chain, similar to how SignalWorkflow, QueryWorkflow, and CancelWorkflow already work. It should:
- Set up a header context via contextWithNewHeader (like WorkflowClient.ExecuteActivity
does)
- Call through the ClientOutboundInterceptor chain (so user interceptors like tracing are
invoked)
- Execute the activity via the test environment's existing activity task handler
- Return a ClientActivityHandle supporting Get(), Cancel(), and Terminate()
Additional context
This is a follow-up to #2158 (standalone activity support). Once this is implemented, PR #2302 can use the standard interceptortest.RunTestWorkflow pattern and extend existing tests like TestSpanKind, TestSpanPropagation, and TestBenignErrorSpanStatus to cover standalone activities — with no new exports from internal/.
Is your feature request related to a problem? Please describe.
There is no way to test the full standalone activity client flow (client → interceptor chain → worker) without spinning up a real Temporal server. TestActivityEnvironment.ExecuteActivity runs the activity function directly via taskHandler.Execute() (internal_workflow_testsuite.go:796), bypassing the ClientOutboundInterceptor chain entirely. This means user interceptors (e.g., tracing, metrics) are never invoked during tests.
Describe the solution you'd like
Add ExecuteStandaloneActivity to TestWorkflowEnvironment that goes through the full client interceptor chain, similar to how SignalWorkflow, QueryWorkflow, and CancelWorkflow already work. It should:
does)
invoked)
Additional context
This is a follow-up to #2158 (standalone activity support). Once this is implemented, PR #2302 can use the standard interceptortest.RunTestWorkflow pattern and extend existing tests like TestSpanKind, TestSpanPropagation, and TestBenignErrorSpanStatus to cover standalone activities — with no new exports from internal/.