x-delivery-count reset to 1 in a flow of resubmitting a copy of the message from a consumer

[gileli121]

Describe the bug

I am testing the functionality of the quorum queue that was released in 2023 (a new feature), and I was checking the behavior of the x-delivery-count header.
I have confirmed in my testing that this value behaves as expected in cases where the consumer process is aborted before acknowledging the message.
However, as a developer was expecting that this flag would not reset in case that I republish a copy of the message after act the message (and I have to do it to update message properties)

So given that a consumer got a message with x-delivery-count = 3 (for example), and the consumer need to "update" (that is: republish and act the original message) some custom property under the header, then in this case, you may expect that the copy of the message will include x-delivery-count = 3 (because this header was also copied), but it was not the case. Its value of it was 0

It looks like a bug to me.

Reproduction steps

Send a message using code:

using System.Text;
using RabbitMQ.Client;

var factory = new ConnectionFactory { HostName = "localhost", UserName = "user", Password = "123" };
using var connection = factory.CreateConnection();
using var channel = connection.CreateModel();


channel.QueueDeclare(queue: "hello",
    durable: true,
    exclusive: false,
    autoDelete: false,
    arguments: new Dictionary<string, object>
    {
        {"x-queue-type", "quorum"}
    }
);



var maxMessages = 1;

for (var i = 1; i <= maxMessages; i++)
{
    var message = $"message {i}";
    Console.WriteLine($"Sending message: {message}");
    SendMessage(message, i);
}


void SendMessage(string message, int messageNum)
{
    var body = Encoding.UTF8.GetBytes(message);

    IBasicProperties props = null;

    props = channel.CreateBasicProperties();
    props.MessageId = $"message_{messageNum}";

    channel.BasicPublish(exchange: string.Empty,
        routingKey: "hello",
        basicProperties: props,
        body: body);
}

Receive message using code:

using System.Text;
using RabbitMQ.Client;
using RabbitMQ.Client.Events;

var factory = new ConnectionFactory { HostName = "localhost", UserName = "user", Password = "cHBk8sJZAEjQTJMK"};
using var connection = factory.CreateConnection();
using var channel = connection.CreateModel();

channel.QueueDeclare(
    queue: "hello", // The name of the queue (should be same also in publisher)
    durable: true,
    exclusive: false,
    autoDelete: false,
    arguments: new Dictionary<string, object>
    {
        {"x-queue-type", "quorum"}
    });

channel.BasicQos(0,
    10,
    false);


var consumer = new EventingBasicConsumer(channel);
consumer.Received += async (model, ea) =>
{
    // Here we just got the message
    var body = ea.Body.ToArray();
    var message = Encoding.UTF8.GetString(body);
    Console.WriteLine($"Received: {message}");

    
    await Task.Run(() =>
    {
        try
        {
            Work(ea, message); // Work is also responsible to mark the message as handled
        }
        catch (Exception ex)
        {
            Console.WriteLine($"Work failed.. error: {ex}");
        }
    });
};

void Work(BasicDeliverEventArgs ea, string message)
{
    Console.WriteLine($"Nothing done with message: {message}");

}

channel.BasicConsume(queue: "hello",
    autoAck: false,
    consumer: consumer);

Console.WriteLine(" Press [enter] to exit.");
Console.ReadLine();

After it printed Nothing done with message: message 1, press Enter to abort the process.
At this point, after the process was aborted, run it again with break point on Console.WriteLine($"Nothing done with message: {message}");
You will see

This is the expected behavior

Exit the process.

3. Replace line Console.WriteLine($"Nothing done with message: {message}"); with:

try 
{
    
    // This is the way to tell that we handled the message so RabbitMQ will not send this message again
    channel.BasicAck(deliveryTag: ea.DeliveryTag, multiple: false);

    
    // Update some value here
    if (ea.BasicProperties.Headers == null)
        ea.BasicProperties.Headers = new Dictionary<string, object>();


    if (ea.BasicProperties.Headers.TryGetValue("my_header", out var headerStrBytes))
    {
        string headerStr = "";
        if (headerStrBytes != null)
        {
            headerStr = Encoding.UTF8.GetString((byte[])ea.BasicProperties.Headers.Values.First());
        }
        
        headerStr = $"{headerStr}x";
        ea.BasicProperties.Headers["my_header"] = headerStr;
    }
    else
    {
        ea.BasicProperties.Headers.Add("my_header","x");
    }
    
    
    channel.BasicPublish(exchange: string.Empty,
        routingKey: "hello",
        ea.BasicProperties,
        body: ea.Body);
    
    Console.WriteLine($"Processed: {message}");
}
catch (Exception ex)
{
    Console.WriteLine($"Exception: {message}");
}

4. Execute the consumer code again.
   While executing it, the counter is 2 as expected
   

But from this point we are going to delete the original message, and copy all the existing headers that includes x-delivery-count = 2 and my custom header:

We copy this object as it is by resubmit the message with that object:

channel.BasicPublish(exchange: string.Empty,
    routingKey: "hello",
    ea.BasicProperties,
    body: ea.Body);

After this line executed, we want to simulate a case that the process crashed.
So just kill this app

5. Run this process again while you setup a breakpoint in the first line of Work method

The issue is that the value of x-delivery-count is 1 but we expect it to be 3 since when we created the message, the value was 2 and I was expecting rabbit-mq to add 1 to 2 so I get here 3.

Expected behavior

The issue is that the value of x-delivery-count is 1 but we expect it to be 3 since when we created the message, the value was 2 and I was expecting rabbit-mq to add 1 to 2 so I get here 3.

Additional context

No response

[kjnilsson]

Not a bug sorry. That is expected behaviour. If you want to track your own republishes use your own header key and add this to x-delivery-count. Cheers. Karl

[michaelklishin]

This is not a bug. If you publisher a copy of a message, to RabbitMQ this is a brand new message. RabbitMQ does not identify messages by their content or properties in any way (with the exception of the message deduplication plugin I guess).

RabbitMQ will initialize certain message properties that it controls for all new messages. Setting them in your own code therefore is prohibited but you can use a different header that your applications update as you see fit.