Feature Request: Programmatic Pause/Resume API for Listener Endpoints

[mhbuckner]

I'm evaluating Wolverine 5.0 for an inter-jurisdictional messaging system where messages flow through RabbitMQ but must ultimately be dispatched to downstream peers, each over its own single TCP socket connection using a request/acknowledgement pattern.

The Use Case

• Messages queue up in RabbitMQ while waiting to be sent to the TCP peer
• The TCP peer can only handle one message at a time (send → wait for ACK → proceed)
• When a peer is unavailable (connection down, reconnecting, extended outage), I need to pause consumption from the queue to prevent retry exhaustion and dead-lettering
• When the peer is back online, I need to resume consumption programmatically

Additionally, I have multiple priority queues feeding this single TCP peer, and I need to implement weighted round-robin consumption to prevent starvation of lower-priority messages. This requires fine-grained control over when each listener is active.

What I Found in Wolverine

Wolverine has excellent reactive pause mechanisms:

• AndPauseProcessing() triggered by exceptions
• Circuit breaker support based on failure rates
• Back pressure via buffer limits

However, I couldn't find a public API to proactively pause/resume a specific listener endpoint from application code — something like:

// Hypothetical API
var runtime = host.Services.GetRequiredService<IWolverineRuntime>();

// Pause when TCP peer disconnects
await runtime.PauseListenerAsync(new Uri("rabbitmq://queue/outbound-messages"));

// Resume when TCP peer reconnects
await runtime.ResumeListenerAsync(new Uri("rabbitmq://queue/outbound-messages"));

The internal infrastructure appears to exist — ListeningAgent, IAgent with StartAsync/StopAsync, AgentStatus with a Paused state — but there doesn't seem to be a public surface to invoke this from application code.

This Is a Cross-Framework Gap

I've investigated competing frameworks and found the same gap exists elsewhere:

NServiceBus (as of April 2024)

• A user raised this exact scenario on the Particular discussion forum: "My application takes messages from an MSMQ transport and then sends messages through SMPP, to an XMPP server, etc. When those connections go down, I would like to stop processing messages until the connection is reestablished."
• They noted that in NServiceBus 3, you could set workers to 0, but this capability doesn't exist in NServiceBus 8.
• A Particular team member responded that LimitMessageProcessingConcurrencyTo won't allow less than 1, and admitted "I'm not sure if that's possible OOTB."
• Another user reinforced: "The 'stop the whole service' approach doesn't work if NServiceBus is being used to send messages out using a CONNECTED protocol, for example XMPP/SMPP/MQTT."
• The discussion trailed off without a clean solution.

MassTransit

• There's a workaround using ConnectReceiveEndpoint via IReceiveEndpointConnector to get a handle you can start/stop.
• However, StopAsync removes the endpoint from the host entirely — it's not a pause, it's a disconnect. The documentation explicitly states: "Once removed, the endpoint cannot be restarted using the ReceiveEndpoint property directly."
• You must design for this from the start — you can't use this approach with endpoints configured at startup. Attempting to do so throws "A receive endpoint with the same key was already added."
• MassTransit's Kill Switch is reactive (based on failure thresholds), not proactive.

The Common Thread

All three frameworks assume the broker-to-handler path should be fully managed by the framework. But real-world scenarios involving:

• Downstream backpressure from connected protocols (TCP, SMPP, XMPP, MQTT)
• Single-connection constraints where messages must be serialized
• Coordinated multi-queue consumption with priority scheduling

...don't fit that model cleanly. This appears to be a gap across the .NET messaging ecosystem.

Workarounds I'm Considering

1. Throwing a custom exception to trigger AndPauseProcessing() — feels like a hack
2. Blocking inside the handler with a ManualResetEventSlim — crude and wastes a thread
3. Bypassing Wolverine's consumption entirely and pulling from RabbitMQ directly, then invoking handlers via IMessageBus.InvokeAsync() — loses the benefits of Wolverine's listener management

Proposed Feature

A first-class API on IWolverineRuntime (or similar) to:

• Pause a specific listening endpoint by URI or name
• Resume a paused endpoint
• Query the current status of an endpoint

This would enable scenarios like:

• Downstream backpressure management
• Coordinated multi-queue consumption patterns
• Graceful handling of dependent system availability

Wolverine has an opportunity to lead here since the internal infrastructure (ListeningAgent, IAgent, AgentStatus.Paused) already appears to support this — it's just not exposed publicly.

Happy to provide more detail on the use case or discuss alternative approaches. Thanks for considering!

[mhbuckner]

Erroneously posted this here rather than in Issues - opened a Feature Request and closing this discussions as duplicate.