3.13 DLX: Bad type for "count" propertie in "x-death" header

[cvuillemez]

Describe the bug

Since v3.13.x, consumers get INTERNAL_ERROR (ERR 541) on some queues containing bad formatted messages for "count" propertie type in "x-death" header:

2024-11-19 10:59:01.413178+01:00 [error] <0.123287970.0>                       {<<"x-death">>,array,
2024-11-19 10:59:01.413178+01:00 [error] <0.123287970.0>                        [{table,
2024-11-19 10:59:01.413178+01:00 [error] <0.123287970.0>                          [{<<"count">>,long,<<"1">>},
2024-11-19 10:59:01.413178+01:00 [error] <0.123287970.0>                           {<<"reason">>,longstr,<<"expired">>},
2024-11-19 10:59:01.413178+01:00 [error] <0.123287970.0>                           {<<"queue">>,longstr,
2024-11-19 10:59:01.413178+01:00 [error] <0.123287970.0>                            <<"myqueueXXX">>},
2024-11-19 10:59:01.413178+01:00 [error] <0.123287970.0>                           {<<"time">>,timestamp,1731986115},
2024-11-19 10:59:01.413178+01:00 [error] <0.123287970.0>                           {<<"exchange">>,longstr,
2024-11-19 10:59:01.413178+01:00 [error] <0.123287970.0>                            <<"myexchangeXXX">>},
2024-11-19 10:59:01.413178+01:00 [error] <0.123287970.0>                           {<<"routing-keys">>,array,
2024-11-19 10:59:01.413178+01:00 [error] <0.123287970.0>                            [{longstr,
2024-11-19 10:59:01.413178+01:00 [error] <0.123287970.0>                              <<"myroutingkeyXXX">>}]}]},

My understanding is that the broker itself write this counter, so maybe a RabbitMQ bug ?

Issue is with v3.13.7 (not tested with v4.0).

Reproduction steps

1. Set a queue with DLX
2. Publish messages
3. Cnsume

Expected behavior

"count" value is in integer not a string.

Additional context

No response

[michaelklishin]

x-death is an array updated by RabbitMQ but it is very common to see applications (re)publish messages with it, something that RabbitMQ does not support.

@cvuillemez RabbitMQ 3.13 is out of community support.

Please provide an executable way to reproduce (a piece of code we can run) against 4.0.3 or we won't be able to help. A single stack trace is not enough, we do not guess in this community.

[cvuillemez]

OK thanks for the quick reply. Not able actually to give steps to reproduce. But yes some applications read and re-publish messages. So OK, probably not a RabbitMQ bug.
But very surprising this issue occurs after minor RabbitMQ upgrade (3.12.14 to 3.13.7) !

[michaelklishin]

@cvuillemez republishing or modifications of x-death headers by applications was never supported.

Minor and major releases of RabbitMQ can and do introduce breaking changes. That's the point of releases that are not patch releases.

All breaking or potentially breaking changes are explicitly documented in release notes, including the first release in a minor series: 4.0.1, 3.13.0. In exceptionally rare cases a bug fix can be a breaking change, but we haven't had one in a patch release in a few years now.

Some breaking changes are behind a feature flag but not every potentially breaking change is worth a feature flag, and sometimes feature flags become mandatory for upgrading, as the doc guide explains in a lot more detail.

[cvuillemez]

Thanks for the clarification.