Could we invert the responsibilities here?

As it is the SlimMessageBus.Host knows about circuit breakers while its an opt-in plugin. I sense a leakage of concerns here.

What if the circuit breaker plugin (and its background host task) could traverse the IMasterBus and its child buses and Consumers to find the ones with matching tags and either start or stop them depending on the circuit status?

That way we contain the circuit breaker logic in the plugin assembly, and the .Host layer is free of that logic.

I originally had a look at this approach, but if a circuit breaker traverses IMasterBus as you suggest:

1. it will be ignorant to any other status changes made by other workflows and then may unwittingly reverse an intended configuration change
2. be side stepped by toggling the IConsumerControl methods directly via MessageBusBase.Consumers (unable to start with circuit breakers already in the loop)
3. require a centralised co-ordinator to aggregate state for all circuit breakers (shifting complexity but still resulting in an inferior experience)

The alternate approach that I investigated was to create a shim/proxy that intercepts the Consumers property in MessageBusBase. It could then trip/open the circuits as required, but would need to change the collection to be that of IConsumerControl so that a proxy could intercept the methods. This approach then cuts off all access to the underlying consumers.

ie.

protected void AddConsumer(AbstractConsumer consumer) => _consumers.Add(new CircuitBreakerProxy(consumer));

In the end the supplied implementation rendered the best results at the expense of being more invasive than ideal, but please let me know if you have another approach.

I feel pretty strongly we need to go for externalization of this logic outside of the .Host layer and into the plugin layer which needs to coordinate consumers and maintain the Started/Stopped state based on the respective circuit state (I see the plugin acting as an adapter).

If anything we could add a factory method to be able to wrap these consumers into some proxies (from the circuit plugin) - or another smart design.

I am less concerned that someone will use IConsumerControl explicitly when using a circuit breaker. And even if so, then if the consumers were never started (or are stopped imperatively) the breaker logic could detect that and could withhold from starting such consumers if the breaker is on again.

The one thing that might get tricky with externalized logic is to maintain identity (or a pointer) to the consumer instance, but if anything we could (assign some identity to these consumers to find them easily by ID). However recalling vaguely the AbstractConsumer instances should remain (not being disposed) between Start/Stop cycles.

I am open to prototyping this logic on the side together if that helps express my intent.

Okay, I'll need to dig into it a little bit, but I am not sure when I will be able to do so. I have some pretty tight deadlines over the next 3 months which are going to leave little time unfortunately.

I think that I have a fair grasp of what you are after, but there are some immediate issues that will need to be overcome as you have described:

1. MessageBusBase does create/dispose the consumers between Start/Stop cycles.
2. There is no reference between configuration and consumer. I added this in the current PR but making it externally visible is not ideal as the objects are not immutable.
3. MessageBusHostedService can be replaced to manage the running state, but due to 1, there is no interception point to stop a consumer from starting if the circuit has already been tripped.