Root cause of connection error not relayed to the caller

[k-wall]

Problem Description

Currently if a sarama based application fails to connect to the cluster, unless the application is happens to have sarama.Logger defined (which is quite chatty for production), the only error message seen in the logs is:

kafka: client has run out of available brokers to talk to (Is your cluster reachable?)

without any more detail. The useful detail of connection refused, connection timeout, certificate expiration is lost.

From an operational perspective (production environment), the makes root cause determination slow. The application that uses sarama needs to be reconfigured to get more information, which is inconvenient.

From what can tell from the sarama client, the underlying error is not propagated to the caller. Is that right?

I'm contemplating a PR to expose the underlying errors back to the caller. Using Go 1.13 wrapped error pattern seems attractive, but this would be an API change for any user with code checking sarama's sentianal error values (if error == ErrOutOfBrokers etc). How would such a PR be viewed?

Is there a less intrusive change?

[dnwe]

@k-wall thanks for raising this issue, I agree entirely and it's a good suggestion.

I think it would be fine for us to move to a model of Go 1.13 wrapped errors and simple document in our Changelog / release notes that there will be a breaking change whereby they must change any error comparison code from:

if err == sarama.ErrOutOfBrokers ==> if errors.Is(err, sarama.ErrOutOfBrokers)

We could also add some helpers to errors.go such as a func IsErrOutOfBrokers that does this for them if we think that would be useful, but I imagine most developers will be aware of the new errors.Is APIs by now.