wagslane / go-rabbitmq

A wrapper of streadway/amqp that provides reconnection logic and sane defaults
https://blog.boot.dev/golang/connecting-to-rabbitmq-in-golang-easy/
MIT License
768 stars 125 forks source link

fix: fatal default log #117

Closed johanneswuerbach closed 1 year ago

johanneswuerbach commented 1 year ago

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.

wagslane commented 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

johanneswuerbach commented 1 year ago

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.

vishal-android-freak commented 1 year ago

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

Flipped199 commented 9 months ago

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?