Every second message is lost with specific queue name

[nikriaz]

Describe your question

I basically follow the "Get Started" manual on the "Topic" page.

This is how I init on the receiver side:

_channel.ExchangeDeclare(exchange: "status_exchange", type: ExchangeType.Topic, durable: true);
_queueName = _channel.QueueDeclare().QueueName;
_channel.QueueBind(queue: _queueName, exchange: "status_exchange", routingKey: "update.*");

and on the publisher side:

_channel.ExchangeDeclare(exchange: "status_exchange", type: ExchangeType.Topic, durable: true);

It works well. But If I replace dynamic queue name to a persistent one like this:

_queueName = "status_updates";  // Use a consistent queue name
_channel.ExchangeDeclare(exchange: "status_exchange", type: ExchangeType.Topic, durable: true);
_channel.QueueDeclare(queue: _queueName, durable: true, exclusive: false, autoDelete: false);
_channel.QueueBind(queue: _queueName, exchange: "status_exchange", routingKey: "update.*");

Then, when messaging is starting, first message is always lost. It repeats after few seconds, meaning if a message exchange occurs after some idle time then the first message will be lost again. It very much looks like consumer and producer need to negotiate something after pause.

Reproduction steps

1. Tried _channel.ConfirmSelect() - no effect.
2. Tried to declare same queue _channel.QueueDeclare on the publisher side - no effect.
3. Updated server from 3.12 to 3.13 - no effect

Expected behavior

Persistent queue name intuitively looks more reliable but surprisingly dynamic name works well while a queue with durable, persistent name loses first message after some idling time.

Additional context

No response

[lukebakken]

Hello, thanks for using RabbitMQ and this library.

Please provide a git repository containing runnable code (console applications), with instructions, to reproduce this issue. You've given some useful information but I really can't spend time guessing how to reproduce what you report.

Most likely there is a misunderstanding of how RabbitMQ and / or this library works that I can explain once I understand what you're actually doing.

Thanks!

[lukebakken]

Really, I can only assist you if I have the same code you're using. Please provide something I can run that will reproduce this issue every time. I will not guess.

Given how much this library and RabbitMQ are used, it is near certain that this issue lies in your code, or your environment.

[nikriaz]

I found the problem. It's hard to believe but fact: the problem is in the queue name. With _queueName = "status_updates" first message after idling is always and consistently lost. With _queueName = "Test" works well! Tried few times to reproduce - no doubts. Try it with your own code. Perhaps, partial matching with routing key is the problem?

[lukebakken]

It's hard to believe but fact: the problem is in the queue name

I guarantee this is not the root cause.

I don't understand why you're unwilling to take some time and provide the code you're using. You get RabbitMQ and this library free to use (as, most likely, most of the software you use), yet you can't seem to find 10 minutes to check your code into a git repository for me to clone, with instructions to reproduce your issue.

You haven't said how you publish messages, either.

Nothing you have said here proves any issue with RabbitMQ or this library.

[lukebakken]

FYI, you can use this project as a starting point:

https://github.com/lukebakken/rabbitmq-dotnet-client-1557

All you have to do is fork it, modify these programs, and open a pull request:

https://github.com/lukebakken/rabbitmq-dotnet-client-1557/blob/main/consumer/Program.cs
https://github.com/lukebakken/rabbitmq-dotnet-client-1557/blob/main/producer/Program.cs

[lukebakken]

I took more time and took what code you have provided and added it to the above project:

https://github.com/lukebakken/rabbitmq-dotnet-client-1557/blob/main/producer/Program.cs#L100-L118

https://github.com/lukebakken/rabbitmq-dotnet-client-1557/blob/main/consumer/Program.cs#L105-L126

As I expected, it works just fine using status_updates as the queue name.

Again, @nikriaz - you are doing something wrong. I can't help any more without your code. Best of luck!

[nikriaz]

Many thanks for such a great input, it's very helpful, I really appreciate it.

So results:

I took your code, just added a counter to see what is transmitted/received:
var body = Encoding.UTF8.GetBytes(counter.ToString());

with status_updates name it was not the only first message lost, every second message gets lost! So, only even messages were received, odd are lost. With Test name everything worked fine. Confirmed this maybe 5 times, consequence change queue name, effect was stable.

Then, I did more starts/stops/experiments and at some point, at receiver started with status_updates name, I've received large amount of garbage (broken text) in my decoded message body and then status_updates name started to work normally. I checked my app and it worked in my app too. However, waiting few minutes, tried again and again, status_updates name: only evens, Test is okay.

I know it sounds extremely strange but maybe this behavior looks familiar for you?
Maybe status_updates is reserved name used by server internally?

I found a mention of this problem. https://stackoverflow.com/questions/51928575/every-other-message-missing-with-rabbit-mq Solution, of course, does not reveal root cause.

https://github.com/nikriaz/rabbitmq-dotnet-client

[nikriaz]

I see that my understanding of the RabbitMQ structure was wrong, I thought a "queue" is like a transport for event bus. But in fact, it's more like consumer buffer. The source for messages is an exchange (not queues) that pushes messages to attached queues. If two consumers are attached to the same queue, they will intercept each other messages and we will see this effect.

So, now I understand more what's going on, even though it's still unclear who is another consumer for a status_update. For sure, there is no more code in my network and I never use RabbitMQ before.

[nikriaz]

Finally got it. Consumer was accidently published to the server and worked there. It was a second consumer for status_update.
Thanks again for your help! You were right from the very beginning.

[lukebakken]

Aha! Thank you for following-up. I was very mystified as to what the root cause of this issue is.