This one in response to #418 in which although we persist a stack trace
to a job row's errors property, we don't reveal it in a panic handler,
which is quite inconvenient for purposes of logging or other telemetry
(e.g. sending to Sentry).
Here, HandlePanic's signature changes to (trace is added):
The value type is string. This is a little non-obvious because Go
exposes it as a []byte, something I've never quite understood as to
why, but I did string because for one it's more convenient to use,
but more importantly, it's the same type on AttemptError.
This is a breaking change, but it seems like being able to get a stack
trace during panic is important enough that it's worth it, and with any
luck there's few enough people using this feature that it won't break
that many people. The fix is quite easy regardless and will easily be
caught by the compiler.
This one in response to #418 in which although we persist a stack trace to a job row's errors property, we don't reveal it in a panic handler, which is quite inconvenient for purposes of logging or other telemetry (e.g. sending to Sentry).
Here,
HandlePanic's signature changes to (traceis added):A couple notes on choices:
The naming of
traceis reused fromAttemptError.The value type is
string. This is a little non-obvious because Go exposes it as a[]byte, something I've never quite understood as to why, but I didstringbecause for one it's more convenient to use, but more importantly, it's the same type onAttemptError.This is a breaking change, but it seems like being able to get a stack trace during panic is important enough that it's worth it, and with any luck there's few enough people using this feature that it won't break that many people. The fix is quite easy regardless and will easily be caught by the compiler.
Fixes #418.