Handle 401 and 403 errors appropriately. Customer had a hard time triaging the error due to this. The following was the update from the customer:
Root cause:
Existing Schema Registry Key was deleted on our side (likely when converting from local user accounts to SSO, still TBD).
This caused our applications to start failing with an inscrutable exception.
org.apache.kafka.common.errors.InvalidConfigurationException: Unauthorized; error code: 401
This would have bene much quicker to diagnose except the real exception which points directly at a Schema Registry issue was obfuscated by confluent's code.
[This code](https://github.com/confluentinc/schema-registry/blob/master/client/src/main/java/io/confluent/kafka/schemaregistry/client/CachedSchemaRegistryClient.java#L574) throws an exception:
io.confluent.kafka.schemaregistry.client.rest.exceptions.RestClientException: Unauthorized; error code: 401
Which quite clearly indicates that there is a problem authenticating to the Schema Registry. Unfortunately though, that exception is handled by [this code](https://github.com/confluentinc/schema-registry/blob/master/json-schema-serializer/src/main/java/io/confluent/kafka/serializers/json/AbstractKafkaJsonSchemaSerializer.java#L175) - which uses [this](https://github.com/confluentinc/schema-registry/blob/v7.7.0-1/schema-serializer/src/main/java/io/confluent/kafka/serializers/AbstractKafkaSchemaSerDe.java#L806) method:
to convert from the Schema Registry-specific exception type into the completely generic org.apache.kafka.common.errors.InvalidConfigurationException: Unauthorized; error code: 401 instance. This is very information-lossy, and destroys any indication that the problem originated from the schema registry.
Handle 401 and 403 errors appropriately. Customer had a hard time triaging the error due to this. The following was the update from the customer: