Due to a recursion issue we've been hitting rollbar limits. To address these issues we temporarily disabling bursting on Rollbar. Unfortunately this seems to result in a panic in the rollbar-go async client.

The fact may be that we are sending rollbar messages even though the connection has been closed. Obviously that's an issue on our end, and we're looking into that.
But the fact that a library meant for logging errors can itself cause these kinds of panics is worrying. Worst yet; because the panic happens in a subroutine we cannot do anything in our application to gracefully handle such issues in the future.
It would be nice if the rollbar-go library had a panic recovery in its subroutine. Maybe have it still default to a panic but give developers a way to override that default behavior.
Due to a recursion issue we've been hitting rollbar limits. To address these issues we temporarily disabling bursting on Rollbar. Unfortunately this seems to result in a panic in the rollbar-go async client.
The fact may be that we are sending rollbar messages even though the connection has been closed. Obviously that's an issue on our end, and we're looking into that.
But the fact that a library meant for logging errors can itself cause these kinds of panics is worrying. Worst yet; because the panic happens in a subroutine we cannot do anything in our application to gracefully handle such issues in the future.
It would be nice if the rollbar-go library had a panic recovery in its subroutine. Maybe have it still default to a panic but give developers a way to override that default behavior.