RabbitMQ connector: non-null content_encoding forces byte[] payload even for charset values like UTF-8

[StyshakSergey]

Summary

IncomingRabbitMQMessage.convertPayload(...) short-circuits to byte[] whenever the AMQP content_encoding property is non-null, regardless of its value. As a result,
messages sent by Spring AMQP's SimpleMessageConverter — which puts the JVM charset (UTF-8) into content_encoding rather than as a charset parameter of content_type
— are always delivered as byte[] to the consumer, accompanied by a misleading warning SRMSG17038: No valid content_type set, failing back to byte[].

This also makes mp.messaging.incoming.<channel>.content-type-override useless for such messages: the override replaces content_type but not content_encoding, so the
early return fires regardless.

Versions

• smallrye-reactive-messaging-rabbitmq 4.33.0 (shipped with Quarkus 3.33.1 LTS)
• Confirmed identical logic on main branch at time of writing

Reproduction

Producer (Spring AMQP 3.x):

rabbitTemplate.convertAndSend(exchange, routingKey, jsonObject.toString());

Spring's SimpleMessageConverter.createMessage(String, ...) sets:

• content_type = text/plain
• content_encoding = UTF-8
• body = UTF-8 bytes of the string

Consumer (Quarkus / SmallRye):

@Incoming("packet-change")
public void onPacketChanged(JsonObject body) { ... }   // ClassCastException [B -> JsonObject
@Incoming("packet-change")
public void onPacketChanged(String body) { ... }       // ClassCastException [B -> String

application.properties:

mp.messaging.incoming.packet-change.content-type-override=application/json
# or text/plain — neither has any effect

In both cases SmallRye delivers the raw byte[] and logs SRMSG17038.

Root cause

IncomingRabbitMQMessage.convertPayload contains an early return when contentEncoding != null. The intent — correct per AMQP 0-9-1 / RFC 7231 — is to
avoid decoding a payload that has been content-encoded (e.g. gzip, deflate, br). However the check does not distinguish compression-style encodings from charset names,
so values like UTF-8 or ISO-8859-1 trigger the same fallback.

Spring AMQP's SimpleMessageConverter has been setting content_encoding to the configured charset for many years (see
SimpleMessageConverter), so interop between the two
frameworks is broken out of the box whenever a Spring producer sends a String.

Expected behaviour

Either:

1. Recognize known charset names in content_encoding (e.g. UTF-8, US-ASCII, ISO-8859-1, …) and continue with the normal content_type-based conversion, using that
   charset to decode text payloads;
2. Let content-type-override (or a new content-encoding-override) force the conversion path regardless of the incoming content_encoding; or
3. At minimum, make the warning message mention that the fallback was caused by content_encoding, not content_type — the current wording is actively misleading.