Eshoponcontainers: [Bug?] EventBusRabbitMQ always creates ConsumerChannel even there is no subscription exists

[cilerler]

As you may see it in here https://github.com/dotnet-architecture/eShopOnContainers/blob/e3daacb9f63adb361776c3fc888612d5fa4ae06a/src/BuildingBlocks/EventBus/EventBusRabbitMQ/EventBusRabbitMQ.cs#L41 ConsumerChannel gets created regardless of if there is a subscription exists or not.

This behavior led application to retrieve the message right after publish. Would you please confirm that if this is an intended behavior please?

[fbarajas-fmg]

I am running into the same issue. Is this intended? I feel like it might be a bug.

[zoinkydoink]

I have the same issue, which is causing my actual subscriber to only pick every second created event, one as stated here

https://github.com/dotnet-architecture/eShopOnContainers/issues/911

[mvelosop]

Hi @cilerler,

Right now I'm adding a centralized logging sink to eShopOnContainers and perhaps this could be a good issue to try it out.

But I don't understand the scenario where this problem occurs in eShopOnContainers and what's the simptom.

Could you describe the scenario so we can have a test case?

I'd like to identify where we should set logging traces to find out where the problem is.

Thanks.

[cilerler]

Hi @mvelosop

Consumer should only connect if there is a subscriber exists and if there is no handler for that message type, it should reject the message _(and if there is DLX/DLK on that queue it will end up on another queue but it is a different topic)_

As you may see here https://github.com/dotnet-architecture/eShopOnContainers/blob/e3daacb9f63adb361776c3fc888612d5fa4ae06a/src/BuildingBlocks/EventBus/EventBusRabbitMQ/EventBusRabbitMQ.cs#L184-L203

it calls the ProcessEvent to process it and even if there is no subscription _(based on code below)_ it sends an acknowledge.

https://github.com/dotnet-architecture/eShopOnContainers/blob/e3daacb9f63adb361776c3fc888612d5fa4ae06a/src/BuildingBlocks/EventBus/EventBusRabbitMQ/EventBusRabbitMQ.cs#L208-L210

Meaning that message has never been processed and it is gone forever.

Please let me know if you need further details.

_(Thank you for picking this one as a test case)_

[mvelosop]

Thanks @cilerler,

I see it's related to https://github.com/dotnet-architecture/eShopOnContainers/issues/500.

Just started to work on this.

Added a few event traces, but I need to go a bit deeper, I'm beginning to work with RabbitMQ.

[cilerler]

You are right, it is definitely the same issue and root cause is what I marked above.
Please, let me know if you need additional assistance.

[mvelosop]

OK, @cilerler, I think I'm starting to get it.

in #500 @heymega comments about a solution that creates the consumer after all event subscriptions are finished, and that seems fine, but it doesn't handle the case of a missing event subscription (a bug).

If I understood correctly, and unacknowledged message will be retried later by RabbitMQ, although it could mean that some messages are received out-of-sequence, but I think it's not needed tha we handle that situation in eShop.

So it looks like it's better to check if a subscription exists before acknowledging the event, for it'd stay in the queue waiting for RabbitMq to try again later. But I'm not sure if that's enough or both changes are needed.

Any thoughts on this?

[cilerler]

If I understood correctly, and unacknowledged message will be retried later by RabbitMQ,

It is not always the case. If the queue has DLX set, and if you reject the message with requeue=false, it will end up in a different queue _(if the separate queue exists)_. If you do it with requeue=true then it will be re-delivered as soon as you reject it.

I usually set up a DLX which delivers the non-processed ones to separate queue which makes sure that no message will disappear ever. And I believe that should be the approach here too.

so implementation steps should be

1. Making sure that the consumer only runs if there is an active subscription.
2. Always reject the message with requeue=false if no suitable subscription exists
3. Have a queue set up with DLX

You may find practical implementation here unfortunately there is no documentation yet, but it is based on both this repository and the one I created earlier so it should be easy to follow it through.

Please let me know if I assist you anyway.

[mvelosop]

Thanks @cilerler, I'll explore a bit more some RabbitMQ basics before continuing here 😉

[mvelosop]

Closing this issue now, as it seems to be solved with PR https://github.com/dotnet-architecture/eShopOnContainers/pull/972, but feel free to comment. Will reopen if needed.

The PR has a set of steps to reproduce the error and confirm the PR solved it.

Cheers.