a9s Messaging: Version Upgrade with Breaking Changes planned for v73.0.0 (End of May 2026):
Within a9s Messaging 4, RabbitMQ 4.2 will be replaced with RabbitMQ 4.3. There are now Breaking Changes between Minor
Versions of RabbitMQ 4, which usually only affect the client side, but require attention. Nevertheless, these RabbitMQ
Minor Versions will be released as Minor Versions of a9s Messaging 4.
Due to recent changes in the RabbitMQ release policy, Minor Versions of RabbitMQ 4 now have a maintenance overlap
period of 3 months. Previous versions of RabbitMQ 4 did not have any maintenance overlap period.
RabbitMQ 4.2 will be supported by the vendor until the 31st of July.
As a consequence of the Data Service vendor's decision to make the maintenance overlap periods for the open source
version of RabbitMQ 4 unusually short, we have decided with the release of a9s Messaging 4 to treat each minor version
of RabbitMQ 4 as a minor version of a9s Messaging 4 as well, although some breaking changes between these minor
versions may occur.
Therefore we do not follow our usual process for releasing, deprecating and unsupporting these versions as Major
Versions: RabbitMQ 4.2 will not be deprecated and unsupported with our default processes, due to the aforementioned
situation.
The version upgrade from RabbitMQ 4.2 to 4.3 will be handled as fully automatic in-place upgrade of the a9s Messaging
4 Service Instances, as is currently the case for all minor version upgrades of our Data Services. Thus, RabbitMQ 4.2
will be unsupported, as soon as RabbitMQ 4.3 is available with a9s Data Services.
a9s Data Service will only support one minor version of RabbitMQ 4 (offered as a9s Messaging 4) at any given time.
Please take the necessary steps now to ensure compatibility with the new RabbitMQ Minor Version to be shipped with
v73.0.0, which will be released at the end of May 2026.
The following Breaking Changes must be considered and the Recommended Actions must be taken before upgrading to
v73.0.0. We recommend to take care of these changes immediately to ensure a smooth transition.
-
Classic Queues v1 Storage (CQv1) is Removed
Starting with RabbitMQ 4, all classic queues will be automatically converted to version 2 (CQv2), even if they are
defined as version 1 (CQv1). If there are existing version 1 (CQv1) queues, they will be converted at RabbitMQ
service start.
RabbitMQ 4.3 removes the original classic queue storage implementation these days known as CQv1. This will lead to
all attempts to fail that try to create classic queues with the following parameters:
x-queue-mode set to any valuex-queue-version set to 1
All applications or automations that should be adapted to not set those parameters for the declaration of queues.
-
Consumer Timeout
Starting with RabbitMQ 4.3, quorum queues will support configurable consumer timeouts. For more information, please
see the RabbitMQ 4.3 documentation of the vendor.
In addition to this change, consumer timeouts are removed for classic queues. Therefore, all applications should be
evaluated if they depend on the consumer timeouts for classic queues and use quorum queues instead.
-
Quorum Queues support unlimited returns
Up to RabbitMQ 4.2, every requeued message incremented its delivery-count by 1, regardless of the reason. Poison
message handling would dead-letter the message once this count exceeded the queue's delivery-limit. Starting with
RabbitMQ 4.3, quorum queues track two distinct counters: acquired-count and delivery-count.
The delivery limit will based on delivery-count rather than the new header acquired-count. This can lead to
unlimited explicit message returns (by nack or AMQP 1.0 modify with delivery_failed=false) without counting
towards the delivery limit.
The header x-acquired-count will track the number of times a messages was aquired by a consumer. And
x-delivery-count will track the actual number of failed deliveries.
All applications should be evaluated if quorum queues are used with poison message handling
and, if required, adapt the application accordingly.
-
Khepri is Now The Only Metadata Store
Starting with RabbitMQ 4.3, the Mnesia Storage Engine will be removed in favor of the new Khepri Storage Engine. The
Khepri Storage Engine was introduced with RabbitMQ 4.0 and is the new default since RabbitMQ 4.2 for all newly
created Service Instances.
All a9s Messaging Service Instance that were updated from a9s Messaging 4.1 (or prior) to 4.2, are still using the
Mnesia Storage Engine. If a9s Messaging Service Instances with Mnesia are upgraded to RabbitMQ 4.3, they will
automatically migrate their data to the new Khepri Storage Engine on the first start. Even though this process
should work without issues, we recommend to use the Strategy to safely evaluate RabbitMQ 4.X minor updates
to safely update a9s Messaging Service Instances to RabbitMQ 4.3. Because if those Service Instances would break
during the Storage Engine migration process, there could be issues to do a rollback.
With the following command it can be identified if the Khepri Storage Engine is already being used:
curl -k -s -u <user>:<pass> 'https://<node-hostname_or_alias>:15672/api/feature-flags' | grep khepri_db
If there is a object with the name khepri_db, then the Khepri Storage Engine is used on the Service Instance.