Temporal test framework obscures stack trace for underlying error

Community Support
,
1

The error output for failed test cases fails to provide meaningful stack traces that point to the actual cause of the error in the workflow. It seems that the Temporal test framework swallows any error stack trace from within the workflow execution code.

It does provide me a stack trace from the failure point within the test itself, but that is not helpful at all in finding the actual cause of the error.

5

Go errors don’t support stack traces.

6

Hi Maxim, thanks for your response. I apologize if I wasn’t clear in my original post. I’m not referring to standard Go errors, but rather the stack trace provided by the Temporal test framework in the error output.

--- FAIL: TestCreateClusterWorkflow (0.05s)
    --- FAIL: TestCreateClusterWorkflow/ResponseBuilder (0.05s)
        response_builder.go:125: 
                Error Trace:    .../pkg/workflows/createcluster/testcases/response_builder.go:125
                                                        .../pkg/workflows/createcluster/workflow_test.go:43
                Error:          Received unexpected error:
                                workflow execution error (type: Execute, workflowID: default-test-workflow-id, runID: default-test-run-id): runtime error: invalid memory address or nil pointer dereference
                Test:           TestCreateClusterWorkflow/ResponseBuilder
        workflow_testsuite.go:968: FAIL:        RunHooksWorkflow(string,mock.argumentMatcher)
                        at: [/home/estaples/go/pkg/mod/go.temporal.io/sdk@v1.26.0/internal/workflow_testsuite.go:425 .../internal/testutils/expector.go:120 .../internal/testutils/expector.go:83 .../pkg/workflows/createcluster/testcases/response_builder.go:103 .../pkg/workflows/createcluster/workflow_test.go:40]

As you can see in the above error output, there is indeed a stack trace.

My issue is that the stack trace doesn’t provide enough information about the actual cause of the error within the workflow execution code. The Temporal test framework seems to be swallowing the more detailed stack trace that would point to the root cause of the nil pointer dereference error.

Do you have any suggestions on how to configure the Temporal test framework to provide a root-cause stack trace or error information from within the workflow execution itself? It would be great to know where exactly in the workflow code this error is occurring.

Also worth noting, I don’t need help on this specific error. I found the root cause using my less-than-ideal methods. I’m looking for a more efficient way of debugging moving forward.

7

Yes, go produces stack traces for panics, not for errors. Nil pointer dereference produces a panic, so the stack trace is available. Hasn’t the nil pointer happened in the following location?

                Error Trace:    .../pkg/workflows/createcluster/testcases/response_builder.go:125
                                                        .../pkg/workflows/createcluster/workflow_test.go:43
8

No, the nil pointer is not in the location referenced in the error trace. As I stated in my original post, it points to the test assertion, which in this case is assert.NoError(t, err).

9

I see. Would you submit a bug report against go SDK ideally with a repro?