If you have a job which panics the only error that's recorded is a short error message. However if it is a runtime error such as a nil pointer access or incorrect use of slices then this makes things very hard to debug because you do not have the stack trace. You end up with an error like the following in the redis hash for your job. Which is very vague in the case of runtime errors.
runtime error: invalid memory address or nil pointer dereference
I've found where this happens and I think the stack should either be logged or also sent to redis as the error message. But I'd be fine if it was just logged as this won't happen often.
https://github.com/albrow/jobs/blob/master/worker.go#L39
Here's an example of logging the stack incase you've never done this before. If you want more examples search for http recovery middlewares as they all have to do this.
If you have a job which panics the only error that's recorded is a short error message. However if it is a runtime error such as a nil pointer access or incorrect use of slices then this makes things very hard to debug because you do not have the stack trace. You end up with an error like the following in the redis hash for your job. Which is very vague in the case of runtime errors.
runtime error: invalid memory address or nil pointer dereferenceI've found where this happens and I think the stack should either be logged or also sent to redis as the error message. But I'd be fine if it was just logged as this won't happen often. https://github.com/albrow/jobs/blob/master/worker.go#L39
Here's an example of logging the stack incase you've never done this before. If you want more examples search for http recovery middlewares as they all have to do this.