Circuit breaker and kill switch not working

[stormaref]

Is this a bug report?

Yes

Can you also reproduce the problem with the latest version?

Yes

Environment

1. Dotnet version: 5
2. Operating system: Windows 10
3. IDE (Rider, VS Code, Visual Studio): Visual Studio
4. Rabbitmq 3

Steps to Reproduce

(Write your steps here:)

1. Add service in startup.cs
2. Use circuit breaker or kill switch in endpoint configuration

Expected Behavior

After the circuit breaker opened the request shouldn't be processes by consumer and throw an exception immediately

Actual Behavior

Request is not processing by consumer but it doesn't throw an exception immediately instead it just wait for a long time before throwing exception

[phatboyg]

Without code, or an example, I'll close this issue.

And you shouldn't use both Circuit Breaker and Kill Switch together, Circuit Breaker doesn't make sense with message consumers.

[stormaref]

I didn't use them both at one time I tried them separately and I'll send you an example tomorrow

[phatboyg]

Okay. It's been tested and works with every transport, you can see the configuration in the unit tests. So if it isn't working, verify that you've configured it correctly.

[stormaref]

RabbitMQTest
you can see an example in this repository where apione publish a message and wait for response but apitwo (the consumer) always throw an exception and when kill switch get enabled it does not immediately throw an exception and instead it just wait for timeout

[phatboyg]

If the consumer in ApiTwo is throwing exceptions, the Kill Switch will stop the endpoint and wait one minute before restarting it. If you make any requests using the request client during the time the receive endpoint is stopped, they would of course timeout as there isn't a consumer available to respond (that endpoint is stopped).

So, it's working as intended.

[stormaref]

So what should I do if I want to get an exception immediately when consumer is unavailable?

[phatboyg]

Immediately? That's a bit of an extreme demand, considering distributed systems. If you want an immediate failure when a remote endpoint is unavailable, stick to HTTP or gRPC that require an immediate connection.

The request client doesn't know if an endpoint is consuming messages or not, it sends a message and waits for a response. If the timeout is reached, the request client throws a RequestTimeoutException. So your adjustment is that timeout, but setting it too short is sort of pointless, and you might as well use HTTPClient to call an API endpoint.

It goes back to the age old question of when do you use messaging for RPC, versus a non-durable transport like HTTP when there are no side effects produced by the message being consumed.

[stormaref]

That's exactly what a circuit breaker must do
Return exception immediately when it's open

[phatboyg]

You'd need the circuit breaker on the client side, before the request client. A circuit breaker on the consumer side would be worthless.

[stormaref]

yes I should do use it on client side
thanks for your help and your nice package it really made it easy to work with the rabbitmq

[stormaref]

maybe you want to keep it open for other users too see