This is a good idea and something that can be done incrementally on a case-by-case basis.

The way that protocol errors work is that whenever we receive a response from the API, there can be one or more error codes returned. For example, the response for CreateTopics v0 looks like this:

CreateTopics Response (Version: 0) => [topics] 
  topics => name error_code 
    name => STRING
    error_code => INT16

This can be read as an array of topics, where each topics has two properties: name (string) and error_code (int16).

The error code can then be looked up in this list. So if we for example receive the number 29, that corresponds to TOPIC_AUTHORIZATION_FAILED.

In most cases, this is handled generically using the createErrorFromCode function:

CreateTopics is a typical example of how this is done:

In this case, we are simply checking all the topics in the returned list, and if there's any error, we throw the first one we find. Obviously we could do a much better job by creating a specific error class that extends the protocol error with more information, and also aggregates all of the errors rather than just picking the first one.

@Nevon From what I gather from the issue it seems like that each of the protocol calls would need a separate wrapped error class (depending on the use case).
I am very much interested in helping with this project as I will be using this library in our company's Kafka consumers.

I think it would have to be on a case-by-case basis. In some cases, it might be enough to create a class for a specific protocol error (this is already done in some cases) and throw that instead of a generic KafkaJSProtocolError. In some other cases, you might need to create a wrapping error class per protocol, as you mention. For example, CreateTopics probably needs a specific KafkaJSCreateTopicError that contains a KafkaJSProtocolError per topic, or something of that nature.

There's also looking into where these errors are caught. I suspect there are a few places where we are explicitly handling KafkaJSProtocolError that may need to be extended to also cover for more specific errors, if we break them out into their own error classes.

I'll give a initial try with wrapping class approach on the CreateTopic protocol. Will try to address the issues and discuss them here.

Next phase for restructure I am targeting (each point will be a separate PR)

1. consumer message API errors
2. consumer connection, rebalance, heartbeat API errors
3. other consumer related errors

After that probably I will be targeting the producer module

The changes made in #1104 unfortunately don't include the actual error message from bubbling up when creating topic. I had to use the debugger to stop execution and inspect the error message around this line:
https://github.com/prithvijit-dasgupta/kafkajs/blob/master/src/protocol/requests/createTopics/v0/response.js#L32

What is the status of this issue? The affecting topic is still not available in the KafkaJSProtocolError. Is there any userland solution to retrieve it?