1

I want to create a go lint rule that requires all goroutines to be launched with a wrapper function that can recover from a crash on the goroutine (this will also take an onRecover callback that will cancel context of request). The pain point I am trying to solve is that a crash on any goroutine will crash the entire server - I want to protect against this.

I currently use https://golangci-lint.run/usage/linters/ for most of my linters.

Two examples of Go routine wrappers that will protect against a crash in the goroutine:

Also please feel free to call out why I should not do this. Seems like an obvious idea and given that this lint rule does not exist I wouldn't be surprised if I am missing something.

D. Maul
  • 341
  • 2
  • 11
  • 2
    A panic usually denotes a bug so recovering blindly will cause wrong results. – Burak Serdar Jun 30 '23 at 01:02
  • The purpose of recovering blindly is to ensure uptime. I would like to come up with a convention where we always recover from goroutine crashes but report the crash as an error that we track over time. In terms of program execution, I think we will need a convention that signals back to the other goroutine that the crashing goroutine failed due to an unexpected state. – D. Maul Jul 04 '23 at 17:57
  • You should do that where it makes sense, like in the middleware of an HTTP handler. Then you can automate log generation as well. You can implement non-blocking heartbeats to make sure goroutines are still alive, and check with an observer goroutine. In general, you don't need a separate goroutine to deal with a panic, simply generate logs/alerts in the recovery code. – Burak Serdar Jul 04 '23 at 21:47

0 Answers0