## RabbitMQ 4.1.0

## Highlights

### AMQP 1.0 Filter Expressions

[PR #12415](https://github.com/rabbitmq/rabbitmq-server/pull/12415) implements `properties` and `appliation-properties` filters of [AMQP Filter Expressions Version 1.0 Working Draft 09](https://groups.oasis-open.org/higherlogic/ws/public/document?document_id=66227) when consuming from a stream via AMQP 1.0.
String prefix and suffix matching is also supported.

This feature:
* adds the ability to RabbitMQ to have multiple concurrent clients each consuming only a subset of messages while maintaining message order, and
* reduces network traffic between RabbitMQ and clients by only dispatching those messages that the clients are actually interested in.

### Support for Multiple Routing Keys in AMQP 1.0 via `x-cc` Message Annotation
[PR #12559](https://github.com/rabbitmq/rabbitmq-server/pull/12559) enables AMQP 1.0 publishers to set multiple routing keys by using the `x-cc` message annotation.
This annotation allows publishers to specify a [list](https://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-types-v1.0-os.html#type-list) of routing keys ([strings](https://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-types-v1.0-os.html#type-string)) for more flexible message distribution, similar to the [CC](https://www.rabbitmq.com/docs/sender-selected) header in AMQP 0.9.1.

### OAuth 2.0 Token Renewal on AMQP 1.0 Connections
[PR #12599](https://github.com/rabbitmq/rabbitmq-server/pull/12599) introduces support for OAuth 2.0 token renewal on AMQP 1.0 connections.
This feature allows clients to set a new token proactively before the current one [expires](/docs/oauth2#token-expiration), ensuring uninterrupted connectivity.
If a client does not set a new token before the existing one expires, RabbitMQ will automatically close the AMQP 1.0 connection.

### Metrics for AMQP 1.0 Connections
[PR #12638](https://github.com/rabbitmq/rabbitmq-server/pull/12638) exposes the following AMQP 1.0 connection metrics in the RabbitMQ Management UI and the [/metrics/per-object](https://www.rabbitmq.com/docs/prometheus#per-object-endpoint) Prometheus endpoint:
* Bytes received and sent
* Reductions
* Garbage collections
* Number of channels/sessions

These metrics have already been emitted for AMQP 0.9.1 connections prior to RabbitMQ 4.1.

### AMQP 1.0 Sessions and Links in the Management UI
[PR #12670](https://github.com/rabbitmq/rabbitmq-server/pull/12670) displays detailed AMQP 1.0 session and link information on the Connection page of the Management UI including:
* Link names
* Link target and source addresses
* Link flow control state
* Session flow control state
* Number of unconfirmed and unacknowledged messages

### Prometheus histogram for message sizes

[PR #12342](https://github.com/rabbitmq/rabbitmq-server/pull/12342) exposes a Prometheus histogram for message sizes received by RabbitMQ.

This feature allows operators to gain insights into the message sizes being published to RabbitMQ, such as average message size, number of messages per pre-defined bucket (which can both be computed accurately), and percentiles (which will be approximated).
Each metric is labelled by protocol (AMQP 1.0, AMQP 0.9.1, MQTT 5.0, MQTT 3.1.1, and MQTT 3.1).

### Feature flags quality of life improvements

The introduction of required feature flags several minor versions ago showed the poor user experience around them. Therefore, several improvements were made to the subsystem and the management UI to improve the general usage:

* Required feature flags have now a soft/hard requirement attribute.

    Hard required feature flags are the ones already in use: the user has to enable a feature flag before upgrading to a version that requires it, otherwise the node will refuse to start.

    Soft required feature flags are the new kind: when the user upgrades to a version that requires a feature flag that is not enabled yet, the feature flag will be enabled automatically during startup. To achieve that, some compatibility code is kept with a soft required feature flag, unlike a hard required one. In the future, RabbitMQ will use soft required feature flags as much as possible. This is only a measure to help users that did not follow recommendations. The recommendations is still that feature flags should always be enabled at the best time for the workload.

    See [#12466](https://github.com/rabbitmq/rabbitmq-server/pull/12466).

* The management UI now shows if a feature flag has a migration function (in other words, it may take time to be enabled), if it is experimental and whether it is supported or not. To enable an experimental feature flag, a user has to tick checkboxes to confirm they know what they are doing. The feature flags UI has other fixes under the hood; the most important one is that a feature flag that takes time to be enabled will not freeze the browser tab anymore (the HTTP request was synchronous and executed from the browser main thread before). See [#12643](https://github.com/rabbitmq/rabbitmq-server/pull/12643).

* Required feature flags are hidden from the CLI and the management UI because there is nothing a user can do about them. See [#12447](https://github.com/rabbitmq/rabbitmq-server/pull/12447).

* Logging was made less verbose. See [#12444](https://github.com/rabbitmq/rabbitmq-server/pull/12444).

See the [full GitHub project](https://github.com/orgs/rabbitmq/projects/4/views/1) for the complete list of improvements and fixes.

## Potential incompatibilities

* The default MQTT [Maximum Packet Size](https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901086) changed from 256 MiB to 16 MiB. This default can be overridden by [configuring](https://www.rabbitmq.com/docs/configure#config-file) `mqtt.max_packet_size_authenticated`. Note that this value must not be greater than `max_message_size` (which also defaults to 16 MiB).
