rabbitmq-server/release-notes/4.2.0.md

## RabbitMQ 4.2.0

RabbitMQ 4.2.0 is a new feature release.


## Breaking Changes and Compatibility Notes

### Default value for AMQP 1.0 `durable` field.

Starting with RabbitMQ 4.2, if a sending client omits the header section, RabbitMQ [assumes](https://github.com/rabbitmq/rabbitmq-server/pull/13918) the `durable` field to be `false` complying with the AMQP 1.0 spec:
```
<field name="durable" type="boolean" default="false"/>
```

AMQP 1.0 apps or client libraries must set the `durable` field of the header section to `true` to mark the message as durable.

Team RabbitMQ recommends client libraries to send messages as durable by default.
All AMQP 1.0 client libraries [maintained by Team RabbitMQ](https://www.rabbitmq.com/client-libraries/amqp-client-libraries) send messages as durable by default.


## Features

### Incoming and Outgoing Message Interceptors for native protocols

Incoming and outgoing messages can now be intercepted on the broker.
This works for AMQP 1.0, AMQP 0.9.1, and MQTT.

What the interceptor does is entirely up to its implementation, for example it can validate message metadata, add annotations, or perform arbitrary side effects.
Custom interceptors can be developed and integrated via [plugins](https://www.rabbitmq.com/docs/next/plugins).

Two new optional built-in interceptors were added to RabbitMQ:
1. Timestamps for outgoing messages
2. Setting client ID of publishing MQTT client

Detailed information can be found in the [Message Interceptor](https://www.rabbitmq.com/docs/next/message-interceptors) documentation.

### Khepri enabled by default

RabbitMQ supports two databases to [store
metadata](https://www.rabbitmq.com/docs/metadata-store) such as virtual hosts,
topology, runtime parameters, policies, internal users and so on: Mnesia and
Khepri. That metadata store is also at the heart of clustering in RabbitMQ. As
of RabbitMQ 4.2.0, **Khepri is the default metadata store for new
deployments**.

[Khepri](https://www.rabbitmq.com/docs/metadata-store#khepri) is based on the
same Raft consensus algorithm used by quorum queues and streams. The goal is to
have a consistent well defined behaviour around all queries and updates of
metadata across an entire cluster, especially when the cluster suffers
increased latency or network issues for instance. It also comes with increased
performance in several use cases, even though this was not a goal.

A new RabbitMQ 4.2.0+ node will use Khepri by default. If you upgrade an
existing node or cluster, it will continue to use whatever metadata store it
was using so far.

If you did not enable Khepri yet, [it is recommended you enable
it](https://www.rabbitmq.com/docs/metadata-store/how-to-enable-khepri):

```
rabbitmqctl enable_feature_flag khepri_db
```

Khepri will become mandatory in a future minor version. Mnesia support will be
dropped in a future major version. These exact versions are to be decided.