Error traces don't show github.com/pkg/errors fill stack trace

[Noah Zoschke]

I use the github.com/pkg/errors package for the reasons Dave Cheney outlined here.

However the shim isn't showing the full stack trace. In the logs from sam local start-api I see:

InvalidClientTokenId: The security token included in the request is invalid.
	status code: 403, request id: fe72a854-d6d3-11e7-b66d-05886b9fd61d: withStack
Traceback (most recent call last):
  File "runtime/proxy.py", line 45, in _handle
withStack: InvalidClientTokenId: The security token included in the request is invalid.
	status code: 403, request id: fe72a854-d6d3-11e7-b66d-05886b9fd61d

Ideally this would be a log with the full stack trace that the errors package helps build up.

not enough arguments, expected at least 3, got 0
main.parseArgs
        /home/dfc/src/github.com/pkg/errors/_examples/wrap/main.go:12
main.main
        /home/dfc/src/github.com/pkg/errors/_examples/wrap/main.go:18
runtime.main
        /home/dfc/go/src/runtime/proc.go:183
runtime.goexit
        /home/dfc/go/src/runtime/asm_amd64.s:2059

That stack trace is only visible in golang with fmt.Printf("%v\n", err), so it's understandable the shim isn't calling into it.

I don't get the inner workings of the shim yet so I'm not sure if this would be an easy fix or not. Guidance is appreciated.

[Farzad Senart]

Hi @nzoschke,

Sorry for the delay, I was overwhelmed by non open source stuff 😄
As the shim process is inside a python process, when returning an error from Lambda, the final words belong to the python process, and it output the error name along with a "dummy" stack trace from the python world.
In your case, you have to wrap your handler function inside a custom "error printer" function to output stuff after returning error from your main handler but before returning to the parent python process.

PS: as described in the README, the behavior of fmt.Print* functions is not deterministic in the context of lambda and cloudwatch and we advocate for the usage of log.Print* functions as they bridge messages to the python logging functions provided by the lambda runtime.

I will close the issue, as it is tied to the way the shim works but please feel free to reopen it or comment below if your need further discussions.