Closed johanneswuerbach closed 1 year ago
I'll approve this change if you will also change the current fatal logs in the library to error logs! I don't ever want the library crashing the users program, at least not with the current errors
While in principle I would agree, I wonder how https://github.com/wagslane/go-rabbitmq/commit/05646d6bbcb264cfb782122b6f52f4383fb95150 would do the correct thing otherwise by default.
As said in https://github.com/wagslane/go-rabbitmq/issues/99#issuecomment-1475447734 we do see unrecoverable errors as result of rolling rabbitmq clusters and currently the application would just hang (unless you provide a custom logger).
Hanging seems worse than to crashing as it usually means the hanging processes aren't restarted and queues just pile up. Yes, you can add your own logger, but this is something you need to know about.
As an alternative solution how about adding a consumer.UnrecoverableError
method that returns a channel and could be used like: https://github.com/wagslane/go-rabbitmq/blob/main/examples/consumer/main.go#L46
for {
select {
case sig := <-sigs:
log.Println(sig)
return
case err := <-consumer.UnrecoverableError():
log.Fatalln(err)
return
}
}
This would allow to detect unrecoverable errors more easily from the outside.
We definitely need something like this. I have observed a situation where the client publishes messages without errors but they actually don't get sent to the broker nor there is any error. This generally happens after multiple disconnects & reconnects. It is difficult to debug bcz there is no error messages
So, after a brief problem in the mq cluster, which may take several minutes to fix, the fatal in the library causes the program to exit. I have not found a method similar to UnreciverableError to catch this error, so how should I prevent the program from quitting?
The
Fatal
log level usually terminates the process https://pkg.go.dev/log#Logger.Fatal, so I think the default logger should do the same.