rabbitmq event exchange plugin

[Systemko]

Hi there!

I'm working on a wrapper library around RabbitMQ.Client in C#. Library extensively uses rabbitmq_event_exchange plugin to be notified about events raising in broker and mantains infrastructure wisely. Now I got stuck on a problem that I can't determine if binding.deleted event raised by itself or it's caused by exchange.deleted/queue.deleted event.
At first, I thought that header user_who_performed_action could give me an answer and all 'indirect' actions were performed by rmq-internal user. But my suggestion was wrong, it doesn't work.
Any ideas how can I achieve this?

Thanks in advance for your help!

[michaelklishin]

Bindings can be deleted by clients but they will also be deleted when things they bind are. binding.deleted is emitted in both cases.

[Systemko]

Thanks for your answer Michael, but it wasn't the point of my question. I couldn't explain it well and that's my fault for sure.
I understand that there are multiple cases where binding.deleted is emitted. It works as expected. But in fact, I need a way to identify the reason of emitted binding.deleted event on a client side. I'll try to explain:

1. Let's assume that we have an application that consumes events produced by rabbitmq-event-exchange plugin.
2. The main goal of application is to maintain rabbitmq objects such as exchanges, queues and bindings in a working state. So, if queue, exchange or binding were deleted, the application must recreate them instantly.
3. If the application received exchange.deleted/queue.deleted event, there's no problem. It can recreate exchange/queue and also corresponding binding without any doubt.
4. If the application received binding.deleted event, there are two possibilities exist:
   • Only binding was deleted. Application restores binding - no problem.
   • Binding was deleted in conjunction with queue/exchange deletion process. Application do not restore binding on binding.deleted event because it will be handled after receiving corresponding exchange.deleted/queue.deleted event. So far, so good.

And this is where the problem comes in. The application doesn't know in which of two possibilities it is. There's no information.
So if application tries to recreate binding only, it might fail because one of corresponding object was already deleted. If application tries to recreate exchange, queue and binding, it will succeed, but wildly inefficient.

So, that's why I need a way to identify the reason for binding.deleted event. Maybe additional message header could be a great option for providing this functionality.

Thanks in advance for your help!